 Oh, I am live. Great, well thanks everyone for coming out to what already has a fantastic start is our DevOps panel. Exclamation point, exclamation point, exclamation point. So I'm having some display issues and that's good enough. That's all the slide said anyways because I'm not here to give a presentation. That'll be later. But what I am here to do is to quiz and hopefully maybe create a little conflict because I think everyone's actually here for blood. At least, I don't think we mentioned that on the call before, huh? So the first thing that I wanted to do is have everyone just go through and introduce themselves and maybe mention a little bit about the perspective that they're coming from. And we're gonna kind of focus around operations, what things matter in terms of operations and especially combined efforts between operations and development around open stack. So I guess if folks just wanna start by introducing themselves. Sure, and should we go into a bit of a background as well? Yeah, just if you can just introduce yourself, maybe talk a little bit about kind of what technologies you're focused on and how that's driving your perception around DevOps. Yeah, absolutely. So my name is Mike Cohen. I'm director of strategic alliances at Big Switch Networks. We're a software defined networking vendor. We build a network virtualization application that has a quantum plugin that provides layer two, layer three, network virtualization alongside open stack clouds. And the interesting, you know, the reason I actually wanted to speak on this panel and then speak about DevOps is I actually believe SDN creates a very interesting opportunity for the DevOps community because it actually essentially takes the network domain, which it essentially been very static and limited to people with very, very specific knowledge and really flattens it, normalizes it and sort of wraps APIs around it. So you can actually now talk to this, you know, either centralized or decentralized control entity and ask it what's going on in the network, ask it what the network looks like, ask it how traffic's flowing all via REST APIs and actually get reasonable answers back via JSON that you can actually parse and make decisions about. And that's very, very different than how networking had worked in the past. And I believe it creates a very interesting opportunity to pull DevOps folks into the fold and actually looking at creating different network management mechanisms over time. Great. Hi, I'm Travis Tripp, I'm from HP. I'm a systems architect in the Converge Cloud business unit. My background is I spent about my first seven years at HP working on applications that were deployed into HP's operations infrastructure, many of which were hosted on HP.com. And then I went into working on enterprise software products for HP that were very operations focused. So I spent some time on a configuration management solution. It was definitely a lesson in scalability as our largest customer had a 400,000 device set of systems that we managed from central installation. And then I moved into spending a couple years helping to launch a brand new product at HP called Continuous Delivery Automation. And that was a whole new set of challenges as we really were trying to embrace openness as much as we could. So trying to pull in what we call the whole DevOps tool chain, going from everything from the continuous integration, your build systems, your source control, up to your testing suites, including we had integrations with Puppet, Chef, all of HP's tools in this space, and then doing all the deployment and the monitoring. So we did everything from nodgeos integrations up to, and including a bunch of the HP products, like if you are aware of anything, like something called Sitescope. And so in that process, I had the opportunity to go out and actually talk to a lot of Fortune 200, 100 companies that were saying, hey, what's this whole DevOps? What's this whole Agile delivery methodology all about? And some of the times it was, we're going in there to try to get requirements from them, trying to get design partners. Sometimes it was about, we're trying to fulfill a proposal for them. And during that process, I definitely had some interesting experiences and some insights that took it from the whole automation technology side to the cultural side. So it's the culture aspects that actually find to be as challenging at times as the automation tool sets. Hi everyone, I'm Kevin Jackson. I'm from Rackspace. So my angle on all this is, I see DevOps as an enabler for cloud adoption. So I spend a lot of time going around companies and seeing how they're trying to move into a world where they have legacy processes, legacy systems, and you're trying to adopt basically private cloud technologies. In a previous life, it was basically the same kind of role. I've gone through the pains of working with developers in one side and managing the system administration team on the other side and seeing the many silos within operations departments, trying to work out how the hell do we work with a very agile development environment mixed with that lovely world of ITIL. So yeah, that's my take. So my take is trying to get to a world of understanding DevOps from how do we get from now to cloud through automation. And I see without automation, you don't really get to experience the full cloud world. You know, essentially, if you go halfway, you automate some things. You basically just replaced your one virtualization system with something else, but you slap the stick on a cool cloud. DevOps is an enabler to actually take that forward into a proper cloud. And I'd say just for introductions, let's try to keep it a little bit more brief. Sorry for people on the end for getting, I guess, ripped off time-wise. Hi, I'm Shreeran Natarajan. I head the cloud technologies practice for persistent systems. Persistent systems is a 22 year old software development company that's helped a lot of innovative companies launch their product onto the world. Just a quick show of hands. How many in this room have their development operations and hardware in the same place, physical space? Well, I see one, about two people in a room of, I believe, about 20, 30, 40 people. Think about, from our perspective, we have about 300 projects ongoing at the same time and they're spread all over the world. So if you are, we are at the cornerstone of agility, innovation, and vastly distributed teams. And we are proponents of DevOps and we've kind of used OpenStack to automate our own internal IT operations. And we also advocate the use of DevOps to our customers to kind of get to success as quickly as possible. Hey, folks, my name is James Panneker. I'm the Principal Systems Architect for Yahoo. My perspective on DevOps is that it is the glue that sort of bridges the gap between prototype and production. When you have a development silo, then you have an operational silo, and you have DevOps that is the group that knows how to span both of those worlds and bring them together and negotiate and maintain that relationship. And I'm gonna go ahead and keep mine short. No, great, and I do appreciate it so we can keep things moving on. And it sounds like there's just a general theme around people, I guess, automating different parts of the stack and kind of pushing culture for getting things combined. And I was just wondering, to start out with, what do people see as some of the barriers for acceptance of DevOps practices? I was gonna say one thing that I saw is there's too much silos within organizations. Just an example, I went into a very large company and they were wanting to bring in agility into their practices and bring in DevOps. And so they bring us into the room and they start talking about, oh yeah, we're gonna enable developers, we're gonna enable all this stuff. And then they go around the room and they start introducing who they are and it's like, oh, I'm this director of strategy of operations and this guy of operations and this guy of operations. Like, okay, you don't have anybody represented from your development side or your testing organization and here you are gonna set your strategy for how you're gonna do DevOps. And it's like, you guys don't even get it from the get go. You're not even including the developers, you're not even including your testing and QA departments. And that's something that you have to consider. You're not doing this just as an operation staff, you're doing this for the developers and for QA. And so that's a big barrier I see is that people need to accept this. Do you think that there's one side that it makes more sense to be driving DevOps initiatives? Or in people's experience, which side of the fence are they coming from? Just to answer your previous question, I think the lack for ownership, I mean, there's no clearly defined owner that can take on the DevOps role, as he mentioned. It's typically operations people. Sometimes we see a lot of developers come in that are frustrated by the lack of agility on the opposite to deliver what they want. And they pretty much wanna take over. And it's our role to kind of bring people together and say, this is gonna keep a grander goal in mind and push people towards, all right, let's take the best of what you can offer, what your problems are, what you can bring to the table in terms of value, and then kind of thread the needle through the various needles, thread through the various needles. So this is an issue I see a lot in the SDN world is we do deployments where, some cases we're working with server teams and DevOps teams. And there's other cases where we actually start working with networking teams, which tend to be not developer centric. They're folks with very specialized skills around using CLIs and understanding networking protocols. And where different IT infrastructure falls from a management, an ownership perspective becomes very important. In that as we deploy, say an overlay technology which only touches the server, it may be easy to deploy or we can pull in development focused people very quickly. And as it starts needing to interact with the physical network in some way, it actually creates a lot more friction because now we need to get both teams in the room, we need to convince them to work together and convince one that they're not seeding control to the other. And there's a lot of friction in that process. And it actually slows down creating a more agile infrastructure, which is what our goal was in the first place. I'm actually curious specific around SDN. I have a lot of specific interest around SDN and how it releases DevOps. Who do you feel, do you feel that one specific side out of those kind of it's moving from two players to three players in this scenario? Do you feel one particular side is driving the innovation towards SDN and that another side is blocking or do you feel that everyone's on board or? I feel that everyone is on board, but they actually don't agree on with what they're on board with. The reality is that server administrators essentially wanna be able to do things and set things up so that they don't actually need to call the networking team to change things. So if you look at the way networks would work, I wanna be able to write a script that spins up workloads anywhere in my data center dynamically. Now to actually make that function, I probably need to fire off a trouble ticket somewhere in between and have someone manually address that trouble ticket to actually connect, provide the right kind of network connectivity somewhere in my data center. Now that's busted from a DevOps perspective, right? It doesn't actually work. So a networking team is actually don't necessarily wanna see control of all those capabilities. They wanna be able to offer that function, but they don't necessarily wanna not have control over it. So part of the challenge we have in SDN is actually offering a solution to both groups that actually gives networking teams the visibility and management control over what's going on, but actually lets them delegate these kind of capabilities and expose them via an API so that folks can actually have this kind of dynamic flexibility about where workloads are placed, for example. And I was also kind of curious, kind of passing a similar question to the rest of the panel, like which perspective of dev versus ops do you see yourself pursuing the problem from it? Just kind of curious about our audience here. I can say myself, I'm way more of a developer than an operations person. And I'm on the opposite end there. I actually come from a pure operational background originally and then the development stuff definitely came later. So I approach from that perspective. Yeah, I've come from the operation side as well. So I've seen a world where it's kind of, I think from the operation side of things, you know, we saw it as a educate dev in how to do stuff, whereas I actually saw the operations team actually get a lot more out of it when they actually understood how to do or how to manage the environment like a developer. You know, the whole kind of utopian world of everything is code. Once it got to the world of managing the infrastructure in that kind of sense, I saw some great benefits, which then fed back into the developer side. Yeah, I'm from the developer side myself. Typically what I see is developers and ops when they meet, each of them claim to be more process oriented than the other. One side comes and says, we need to have processes. The other side says, sure, we've got processes of the Azure. So what are you talking about? So typically it's the agreement of what needs to mesh together is the problem. And what we need to identify is what pieces of process can it make sense from the development angle? What pieces make sense from the operations angle? Operations are typically, let's get the lights on, let's keep the process going while the developers' processes are focused on creating new and different features and kind of getting the better value out there. What we need to kind of balance the both the endpoints of these processes to choose which process methodology you'd like to adopt. Is this working? I definitely started purely looking at from developer side since I developed apps for a while deploying them, looking at IT, blaming them for everything and they were looking at us for what do you mean? I was going for my five nines and you guys just keep screwing it up. But then you start looking at it and realizing when you talk DevOps, this is one of the things that we've talked to a bunch of companies about. It's really a journey, it's an iterative process that you have to go through to reach that end game. And sometimes it makes sense for them just to start with taking OpenStack and creating some OpenStack based clouds and kind of mimicking their production environments in OpenStack so they can stand them up and tear them down and do their dev test processes that way and build up a level of trust that hey, this thing can replicate our production environments that we can deploy into these things and start building this up so that you can get your automation going all the way because when you get to the end game and yes, the company may have five levels of test phases, regression, functional, performance, show all these things that they typically have to go through but when they get a requirement that something has to be out in a half hour which we had several financial services talk about you need to get to this automation point where you trust your systems and you're not gonna get there overnight necessarily, you're not gonna trust your automation overnight but you have to reach that point and you may start with the dev test kind of scenario where you're spinning up environments in dev test but getting to where you actually believe in your systems and your automation. So I think for people who have kind of the operations perspective, what do you think developers can actually learn from your ops folks? That's a good question. One of the things that our developers really I think benefit in the dev ops scenario is that when an operations person goes live there's actually a series of steps that need to make sure a little like a checklist that needs it to come through is it monitored, is it reliable? Where's the fault tolerance? And then the operations person also can will usually bring table the perspective of scale like what happens at scale? What happens when things break at scale? What are the unique and interesting ways that things shatter and by bringing those to the devs they can actually help set requirements to devs and say these are the things you're going to encounter and what you're gonna need to anticipate and resolve and that gives the devs something to actually work with. In the dev ops combination one thing that keeps the fault of the table is architecture. So if you don't have the architects on board that kind of guide through the scale and the design of the thing so the developers probably know the little sandbox but they don't kind of look at the overall picture. Ops also defines okay this is my five nines but if it doesn't achieve anything so it's no point. So you need to have architects at the table as well. And I guess to flip it what can the operations folks learn from the developers? I would say one of the big things that you know the operations folks can learn from developers in my experience is a lot about agility and innovation and on the operations side you're measured on actually keeping things working not necessarily not given as much credit for changing them but making sure they don't actually break. On the development side you're giving credit for actually creating new things and creating new capabilities and enabling something that was not possible before. And bleeding together of those things I think would be is really what we need now. I was curious too since we have you here what can the opposite and the developers learn from the networking folks? Yeah so I would say networking folks have a lot to offer in that domain and that they have a ton of experience running very, very resilient systems and architecting around a lot of complexity and doing it in a way that is extremely resilient. One of the worst things that can happen in an operation domain is the network going down it brings everything to a halt. So the network industry has designed a large number of standards and also a huge amount of training you can go through, assist, go to CCIE. There's a ton of very standardized training you can go through to understand how to interact. How to manage a large number of very complex systems. And then on the DevOps side really it's a lot more, I don't want to say seat of your pants but there's a lot more kind of, you know anything goes let's kind of put it together and see what works and networking runs in a very, very different way. It's much, much more structured. And as you start breaking down that structure you lose some of the reliability that people have come to rely on. So I guess the next thing that I was wondering people's perception on is I often wonder if, you know especially the people at this conference and in the room are maybe, you know the bleeding edge of what's going on or do you think that this is going mainstream? Just in terms of these types of automation practices. I think it's going mainstream. We are at the bleeding edge but it's definitely going mainstream. I mean, like I said before I wouldn't have walked into these rooms with the super large the biggest corporations in the world asking for this if they didn't see it going mainstream. Now right now maybe the CIOs are the ones kind of reading the magazine saying hey tell me what this DevOps thing is all about but if they're looking at it it means it's turning the corner. Yeah, great, I certainly see it as mainstream. So I mean if you look about, you know a year, 18 months ago people were talking about DevOps being what wasn't a role, you can't really define it. Now you actually look at all the jobs that are available. You actually ask for DevOps and engineers. I think that kind of says that, you know people actually want all this and it's actually mainstream and the skills. There's jobs out there for these type of skills. I was wondering if someone could pick and I know this is kind of a lame question but it's going to be fun. Could people say what do they think is the most important tool for DevOps? The human. That's true. I think there's too much focus on the tools. You know, there's a lot of people going hey, I run Puppet, I run Chef. You know, that does not make you a DevOps house, that just makes you efficient. What actually helps with DevOps is actually getting human strategy talked to one another. You know, it's getting the ops guys to talk to the dev guys. That's your main tool. I'll play to the crowd and say after the humans comes OpenStack. What, why is that? Pandering? Well, pandering has got a lot to do with it. We use OpenStack internally to run a lot of our operations and we've had a lot of success kind of not reinventing the wheel in terms of provisioning nodes, setting it up and kind of being able to shut them down once the project is over and all that stuff. So, there's a lot of things that come out of the box that we've used internally. Actually, the probably greatest tool for DevOps would actually be any automation tooling they use because that's when you have the DevOps folks that are automating the processes for the straight operations people that makes their job easier. And then when things are not easy for them to automate or represent a serious problem in the product, then that's a requirement that can then feed into the developers. Yeah, I'll probably stick with Puppet and Chef as the greatest tools for DevOps. So, I mentioned before that SDN actually can be a very interesting new tool for DevOps as well because it can actually give you APIs into a part of your infrastructure that you never were able to touch before or never really able to modify. So, I definitely encourage folks after this to kind of investigate some of the stuff going on with open source SDN controllers and the kinds of things you can manipulate because I think you'll find a new tool that can actually be a very enabling technology. So, we talked about OpenStack and I guess more generically, infrastructures of service APIs. How does that, I guess, play into DevOps in general? How is it an enabler of that? Well, I know that from my early experience working with getting things on HP.com, if we wanted to get new environments set up, it took a very long time. It was very slow. And with your new APIs, everything basically being exposed to you as a developer, your operation staffs could create standardized environments for you that mimic their production environments that can help you. Or they can just give you direct access and say, hey, here's your account. You guys want to request some new infrastructure to go and play with it, fine. So, it gives you so much more flexibility and agility. I think one of the greatest things about infrastructure service in general is the ability of DevOps and operations to actually get out of the way. You know, we don't want to be a blocker for developers to do their job. We just want them to do their job. Our job is to give people access to our resources. Whether or not that that's our customers on the outside or our developers on the inside, one way or another, we have to connect people to these things. And when we stand between our developers and getting their job done, that's a position we never want to be in. And so infrastructure as a service gives us the ability to say, you know, you need resources, we define quota, whatever, however your system works, and then you hand it over and say, great, you do it yourself. The other thing I think that's, you know, becoming more prevalent and working really well is the plug-in model. You know, it happened in networking, it's happening in storage, the idea that you can actually, you know, there's a high-level abstraction layer that lives inside OpenStack and beyond that can live any number of implementations and you can actually create, you know, cook up your own implementation on top of a vendor solution. You can cook up something on top of open source. You can cook up something fully homegrown. And then you can connect it to OpenStack via relatively standard APIs. And I think that is a very, very useful ability. I was actually wondering, do people have experience with, let's say, indicators that a company might be culturally destined to fail at DevOps? I'll actually say pride is probably the biggest thing. When you're trying to form DevOps but you still find yourself managing two very prideful, arrogant organizations, you are gonna be destined to fail. The only way these things work is when everyone kind of puts aside their self-importance and realizes that they are not the most important thing, the most important part of the organization, the buck doesn't stop there. They're just one more part of the great machine that is the whole organization. And the other aspect I would add is, you know, there's an ownership, you know, anytime you see a battle for ownership going on, you know, we have customer meetings where, you know, it's not clear which group we should be talking to or the fact that, you know, the groups disagree about how things should be done and don't wanna get in a room with each other. You know, that's a very bad sign. And, you know, it makes it very, very hard for them to work together. It makes it very, very hard for them to agree on how any kind of API handoffs would work or how any kind of automation technology would string together. I have a specific example of a different company. I mean, they're talking with them. They, it's the operation staff again, so that's an indicator. They don't have the rest of the company in there. But they're talking about automation tools. And we find out that they actually had an HP solution that they were using called application lifecycle management that could deploy some lab on demand infrastructure. And we asked these guys, do you guys use this? Does this matter to you? And the operation guys go, no, that's the testing. We don't care about that. So it's just an indicator when they just sit there and basically talk to the hand when you get outside of my production space. So I was interested just in general, what do people think about, I guess, monitoring or specific types of tooling around monitoring or just general processes that are gonna lead to more automation success? It's vague on purpose, fill it in. All right, I'll just take whatever direction I want with it then. You know, one of the great things about monitoring is that being paid sucks a lot. And we have, I'm fortunate to work on a team so very, very smart people. And one of them has actually gone through extreme efforts to automate as much of our paging as possible. So not only now when something goes wrong, does someone get alerted, but does it come up in an IRC channel where you can acknowledge it from there by giving the body command? But from there, we can also start to examine other things. For example, if one of our clusters is starting to run low on IPs, we can automatically kick off a request for more IPs. So by automating our automation and adding additional tooling to it, we can actually try and get a little bit closer to a Skynet-like operation. Yeah, so before, this is something I used to work for. Before we got to a world where it was a little bit more DevOps. You know, there was the traditional monitoring. You know, it's had all your Nagios systems, that kind of stuff. You kind of hoped that actually told you the full story. Moved into a world where a team was a lot more successful in understanding DevOps and actually had the guys actually talking to the operations staff and vice versa. We got to a world where we had very specific monitoring in place. This was to do with classified adverts. So we could actually see when things were going bad, when adverts start dropping off the site. So instead of having like very generic, kind of, hey, the web servers are running, we went down to the level of detail very specific for the application. And I don't think we'd ever get there if we didn't get these two teams to actually talk to one another. I was actually curious, what do people think, you know, what are people's opinions around tools for multi-node orchestration? Just curious, what are people's kind of favorites, things that they try that they didn't like? Multi-node orchestration? Multi-node orchestration for actually, you know, things, I mean, heat would be a prime example. I guess, what's the place for things like heat? And I'm just curious, what other tools people know and what tools like that people got success with? Yeah, so the one that I've seen, a fair degree of success, but I have a, I'm sorry for the right scale, but I have a love-hate relationship with those guys, but you know, I've seen some good stuff from there, in this particular organization, but I've also seen the fact that, you know, we've, you can get very quickly locked in to those kind of things and just trying to undo some of that work to move to something else was a pain. But whilst it was going good, it was very good. So I guess, oh, go ahead. To be frank, most of what I've seen has actually been homegrown, you know, homegrown solutions that people have layered on top of existing things they had, you know, and they've been using Puppet or Schaff and you know, but it's actually, it's actually ended up being very homegrown and sometimes it's worked well and sometimes it hasn't. But a lot of people, you know, most of what I've seen so far has been people cooking up their own. So I think that leads, so pretty good, given that maybe people have less answers about that specific topic, what are the unsolved problems of automation or of DevOps? You know, what are the next things that need to be solved? So I'll actually jump back to your last question while you're asking about heat. And that's actually a particular interest of mine right now. I've been in participating in all the heat sessions and also I have been sitting in on a Tosca board for OASIS topology orchestration for cloud applications and looking at some camp specs. And it kind of leads into your next question. And it's one of the things that we look at and say there isn't really one single tool that handles everything today. And one reason for that is that there's really different needs. You go into some organizations and the people are going to want to be down at the very low levels. They're going to want to script everything. And that's fine, that works great for them. Then you have some people that they need to have higher level visibility. They need to understand things from a kind of a more logical level, see how this thing all maps around. And some companies seriously, they don't want to have everything at such a low level of orchestration like he may provide you today. They may desire a higher level type of thing that they can walk up and show their boss and he understands that the application view of things versus the infrastructure view of things and he can visualize it. And so I think that this is an area that is a big dialogue right now and it's the orchestration tool set. And I think it is kind of the next big thing. Coming back to the question, what's next for DevOps? I don't completely agree with that that DevOps has gone mainstream. It's getting there, but it's quite a ways to go. But I think it'll get there and the next question that's going to come up is, what is the value that it's providing me? It's going to become more, what people from the company's perspective is going to be, what has been cost center has been married to a value center and I need to see what value I'm deriving from it. What is the innovations that's coming out of it? The people that are kind of becoming the VP of DevOps need to be very fine tuned and aware of what value they are bringing and they need to keep very constant and frequent metrics on that. I think that's where it's going. So I guess what are some of the, oh, sorry, do you want to jump in? What are some of the skill sets that you think people need to be DevOps? And do you think that those skill sets are overall lacking in the market? I think, I would say the two, two of the key skills, the most key skills that I think you need is actually personality and charisma and you have to be able to, because you really do need to operate between these two worlds and try and bind to these two groups and make them get along and help them maybe get over themselves. On top of that, you need automation skills. You need development skills to understand where the developers are coming from and you need operational skills to understand what the problems are when deploying in an operational environment. You have to be able to help anticipate some of these problems. But I think the key, most key skill is still the personality to kind of help everyone get along a little bit. I think it's absolutely essential that folks in this world, they've, if you rather spend time in the operational world or you at least intimately understand that space because the requirements of, the uptime requirements, the kind of SLAs you have to deliver for, you are extremely high and different than you've probably dealt with in a more traditional development environment. And you really need to understand that the tools you're building, the kind of automation you're designing, has to stand up and someone will get paged if it doesn't and you actually think, that's a shift from the average developer and the way they operate. So I guess from my perspective, this will be a slightly lower question from my perspective, but it feels like DevOps has evolved out of Ruby and now we're sitting here representing OpenStack which is evolving out of Python. So how do those two things come together? They're both object oriented. So as long as you're trained in your objective, you're gonna be fine. But is that it? Is it, if you wanna do DevOps, then you should program in both Python and Ruby? I think that's actually an important skill. But it doesn't have to just be Python and Ruby. There's plenty of large enterprises that have a lot of tools that feed into their Dev systems that are still based in Java and other languages. So I don't think that you can just say, if you're DevOps, you have to be Ruby and Python only. If you wanna be playing in the chef and particularly the puppet space, OpenStack, then right now he has Python and Ruby. Do you think it's reasonable? I mean, it's not just about programming languages, right? It's about an entire tool chain, right? It's mocking and stubbing tools and unit test frameworks and I guess virtualization automation tools. Do you think that's reasonable to say that actually all of us should be able to simultaneously work in all these development environments? I think you're assuming that, you're assuming that it's all development-oriented being DevOps. So I think some key skills about DevOps is actually fundamentally understanding Ops. But to have, I think you just need more of an appreciation and an understanding of a language rather than actually knowing the language to be DevOps. You don't have to be a developer to be DevOps. You'd be an Ops guy who just has a very good appreciation of what can and cannot be achieved in the development environment. I guess we have a microphone there. So if anyone wants to stand up and fire questions at us, I think that's pretty reasonable. I'll give people, I think we have a mic if you want to, can you? I'll just shout really loud. Yeah, shout really loud. This is even being reported. The question from David was, what tools, what automation tools are missing in the OpenStack ecosystem? Even though I don't see a camera, it's maybe I don't even have to re-ask. I don't know if it's an automation tool, but the ability to upgrade OpenStack is a big problem. So that's something that needs to, Rob Hirschfeld had a very great talk on that yesterday, which I think was great. Upgrading is obviously one of the big ones. Deployment is another one. Heat is trying to address that. And I'm watching that cautious and see which direction it's gonna go. But when you think in terms of needing to deploy 20,000 node cluster, you start to really be concerned about how you do it and how you present a high SLA to your users. And that's when other tooling like secure methods of live migration, all these other things that really come into day-to-day, instance management really come into play. I can't even resist commenting on this one. I mean, for me, the most important gap that's actually being filled right now is we really need to start collaborating on continuous integration as a service. And I've had a lot of, spent a lot of time in the last month, like understanding Zool and OpenStack DevGate and sorry, I know I'm saying it wrong, but kind of everything that's going on in OpenStack Infra. And I really hope that going forward, companies can stop building their own CI systems and start collaborating around centralized CI as a service. You know, the aspect I would add on the networking front is we've actually seen a lot of work that's coming right now on the quantum side around network services who think about firewalls and load balancers. And there's a lot of devices that live, essentially outside the OpenStack domain today, the OpenStack domain today, and they need to be, essentially, virtualized and available in a programmatic way to tenants and to tenant networks. And that's one of the things that we're trying to tackle in the quantum world at this point. We have another question. I work, I sometimes say that IPv6 is this giant monster just on the other side of the horizon that everyone knows exists, but everyone thinks we can wait till next week. It's only for now, right? IPv6 is kind of a big deal where I'm coming from and definitely looking forward to seeing better integration and support inside of OpenStack. Any other questions? Someone just shot it because I'm having a lot of trouble seeing. Oh, wait, perfect. Now I can see all of you. Any other questions from the audience? Yes? Oh, and we have a microphone. Thank you for using our microphone. You guys have danced around defining what DevOps is. You've claimed that there is no real canon of software that has to be there for DevOps. So now I'm gonna ask you, what's your elevator speech for? What is DevOps as opposed to what is not? Can you do that in one sentence? I gave mine already. DevOps is the bridge that combines the developer silo and the operational silo. It's a group of people that have skills that fall on both sides of the aisle. Doesn't really say what's there, what's not. They're really smart nerds. I think that DevOps is the collaboration using automation techniques to rapidly deploy software and to stand up infrastructure in a way that enables faster time to value for your business. Yes? Again, it's hard for me not to jump in here. I think no, I think that one of the lessons to begin with for me. There is a camera. Oh, there is a camera. Oh, the question is does this kind of, is there an erosion in overall quality of service because we're combining developers and optimizers? And I guess it kind of hints to, is there this inherent compromise that's gonna come out that erodes the overall service quality? And I can't help but jump in and say, I think it actually improves service quality because it's taken the operational expertise and it's forcing everyone to start thinking about building everything as a service, which I think leads to building fully automated platforms for delivery as opposed to ad hoc processes for delivery. I think the purpose of DevOps is to prevent the erosion of either of those. The purpose of DevOps is to understand both perspectives and find a way to make them both work. So I guarantee you that even before you get to DevOps, a lot of people were putting bad code out into production and with DevOps, the theory is you can get your fixin' faster. And just like this week, I got an update on my mobile app from I think Comcast, I think, I don't know if he's in the audience, but, and it had a bug and my battery drained. The next morning there was another update. Oh, and the little tagline said fixed bug that was deployed in the last version. And part of that is because they were deploying it to production and getting that app out there and the services that backed that out faster. I don't think there's gonna be erosion in value. It's just the means to measure the value have to kind of keep up with the pace of innovation that's happening in DevOps. And pretty soon you'll see that the value that you get out of DevOps is much more than what you did in your traditional silos. I generally agree with what's been said. You know, I will have to caveat. There's a right way to do things and a wrong way to do things. When done correctly, DevOps can actually make things better and that it actually can lead to more automation and you create an automatable process. You can now test it better and deploy it more clearly than you would have before. You know, that's things done correctly. Things done incorrectly. You say, you see to your pants you can do whatever you want and you start rolling out random things. You can actually make things worse. So it doesn't necessarily prescribe that things are better or worse. It actually depends on how you do it. DevOps still has the notion of release gates. It doesn't, it doesn't mean, in some shops maybe it means I press a button and it automatically goes through. But there still is a notion of release gates of going this thing goes through this QA process to this QA process and this build is actually approved to be pushed out into production. So just because you say DevOps doesn't mean there's no such notion as release gate and no such thing as quality. I think are we, is our stop point 40 after? Not that I can even see anyone to get it. 230. Oh. Yeah, great. Well, thank you everyone for coming and especially can we get a round of applause for our great panel who is nice enough to answer some questions for us.