 All right, so thank you all for coming you guys must be sort of eager to leave here and go straight to the bar or the happy hour wherever yeah so so my name is Ashish Narkarni I'm the dumb moderator today I don't know what this topic is about I'm just gonna ask questions and then hopefully by the end of the panel I'll learn something out of it but we have a very entertaining and vocal panel so I will leave it to them to to introduce themselves and tell us a little bit more about what they do what the company they're from and what what stuff we can talk about today so Monty you want to start sure so hi my name is my name is Monty I work at Red Hat and in the Office of Technology doing CI and CD related things that that is largely because in my role in amongst my roles in the OpenStack community I started the OpenStack CI CD team that we refer to as Infra who who you saw several of our erstwhile members of up on stage in the keynotes this morning so which was really really super cool and also sit on the OpenStack technical committee and the board of directors because apparently being on two different governance bodies is a great idea it's a great way to spend your time and in my in my spare time working on all of these things I I have a sort of an unholy allegiance to a combination of Ansible and Puppet which scares most people as well it should so but I'm here repping Ansible today so so I believe I'm supposed to punch you in the face okay yeah sweet awesome am I allowed to punch you back I mean I would prefer it if you didn't but but I suppose it would be not I'll hold you guys thank you thank God Chris is the Chris is the middle passenger that's right keep you guys yeah you could just punch me whereas I have to ride down in the declarative dear so yeah yeah exactly eventually we'll converge the state of you having punched me Chris you want to go next all right that will be hard to beat hi everyone my name is Chris Logan I'm the practice lead at Dell EMC for application modernization in our services team primarily we are we develop solutions for customers to help them leverage a variety of technologies in the cloud native space all the way from applications practices like agile lean DevOps CI CD as well as platform as a service so technologies like cloud foundry and on either hyperconverged infrastructure or on customers on their own architecture so primarily it's all about understanding what their business motivations are what their challenges are how to get them engaged in a solution and how to start with that on it so looking forward to the panel hey I'm Nigel Kirsten I'm CIO at Puppet which is sort of a strange title given what I do I had people who run back office IT and business operations but I run the SRE group and I run community I've been at Puppet about six years which is sort of forever we run the state of DevOps report every year we've been doing that five or six years long before anyone with any money actually cared about DevOps yeah I have a question who's actually read the abstract for this panel of the people who read it who would like to actually hear about those things and and more importantly for those who haven't read the panel or the have read the abstract do you agree or disagree because I think that's the main topic we are going to start off with right in the source in the spirit of full disclosure we were just exchanging emails on questions and someone I think Nigel started by saying he disagreed with the abstract so we said why not what's better than start off with that question you disagree with the abstract so that's so the abstract is well the topic is infrastructure limitations on DevOps and I believe Nigel you disagree so yeah I feel like the premise of the abstract to I guess set up the straw man that we're all about to either knock down or try and support was that agile application development and DevOps practices are actually incompatible with managing infrastructure in a traditional way and I disagree so who wants to mount the case for the both looking at you yeah so I I think actually that there is a case for both but for the most part I think that there it's usually the challenges if there are some I think come into more organizational issues and how organizations can realign themselves to accomplish this think Conway's law it's difficult for organizations to change the way they operate and so they manufacture challenges because of resistance to change I think in Greenfield environments where you have a clear path to how you want to accomplish this I think technology solutions are pretty straightforward I mean I think it's actually pretty easy to solve most problems in Greenfield environments you don't have any customers you're not actually making any money out of it the reality is for most companies all of the most interesting stuff is what often gets termed legacy which is the software that actually supports the business yeah I was I was having a thought so I have my normal sort of things that I like to toss at at some of these concepts to whatever but it just sort of struck me as here that so that there's this this whole cloud native concept which has some positives and negatives and whatnot but but pop into my head there's this there's been this theory that we've got this new generation of kids running around who are the digital natives right and they've they've grown up with computers all their lives so clearly they're going to be they're gonna do stuff on the computers that like blows our minds right and it actually turns out they're morons as it relates to computers or at least not any better than we are because they've had really really well functioning computers in their pockets for their entire life so they they don't have a tinkerers a natural sort of tinkerers let's take apart this computer because they take apart the computer in their pocket it stops working very quickly I think the problem is actually worse for the children of those of us who are actually tinkerers yeah I read a really great piece talking about how you know if your computer broke when you were kid like our age my mother and father weren't going to fix it yeah like if I had to fix it and there was no internet yeah you weren't actually your kids computers guess who fixes it yeah you are and if you know especially if you work in technology your router or Wi-Fi goes down at home that's sort of this professional pride of yeah fix again yeah I'm gonna I'm gonna make my thing right and so it makes me so my concern like it because I think there's a bunch of of really good concepts that are that are encoded you know in you know in the in the you know sort of cloud native description of how things go and there's there's some really positive stuff there I have a having a long-standing concern that that there's this undercurrent of because we've all decided the developers the most important thing in the world for some reason and and that we should we should make them happy no matter what but there's this undercurrent of interest in being able to to just write some code and not have to know how any of that infrastructure crap works so if I paraphrase it for those people tweeting the crowd yeah Monty says cloud native developers are morons that's that's absolutely what I just said yeah all cloud native application developers are morons no but that's that's actually I mean there's another problem which is that we we we only seem to be able to produce thoughts that are tweetable and it turns out that the reality is much more nuanced that than that in case I really worry that we're building a culture of people who have ceased to want to know how the underlying things work I actually like it when I don't have to reconfigure my router every day that's fantastic right but I also sort of want to know some amount of of how that stuff works because then even if I'm using an easier framework on top of it I can understand how that's I before OpenStack I worked for my SQL as a database consultant and I did a lot of performance tuning and the number of people who thought that there was this immense black magic going on inside of the database that they would just let the database handle it I'm like well here's what happens when you're doing a join there's there's a nested for loop literally there's a nested for loop in the code that it's just written in C right so it's faster than doing it in your in your interpreted language but it's not it's not magic there's still if you have a billion rows and you're joining them with a billion rows you have you have a billion squared iterations of a CPU that's got to do something and so you can it turns out you can easily reason about what is the cost of doing this thing like it's not it's not hard if you learn about it right but it seems very scary and black magic to people and they don't really want to know how SQL works behind the scenes and it got it scary and all these because we're essentially piling abstractions upon abstractions yeah and like at the moment and they're all leaky yeah they're all leaky I and I think they're they are beneficial like I'm not trying to say we shouldn't do that but I I want to make sure that I'm my concern is that culturally as a tech community we don't go so far down the road that we we encourage people to to value being ignorant right like that that sometimes you may not be able to know something I don't know anything about how NFV works people keep saying NFV and I'm like but you know I think that when you think about how most business software is developed you end up with specializations of skills and so I think that's been the case probably for you know past 20 years at least yeah and I think culturally that's not changing any time soon until recently with the advent of full stack developers and with combinations of DevOps teams yeah I think that without I think that cloud native gives you somewhat of a better model for how to architect applications in a way that can that where you have a better likelihood of being able to abstract away so totally yeah so the question then is since we're talking about cloud native and since we are at OpenStack and since we're talking about dev and ops oh how do you balance it out sort of a open-ended question so you know is there any secret stuff like you talked about CICD at OpenStack if there was no CICD at OpenStack what would OpenStack look like in the context of cloud native well if there were no CI for OpenStack I don't think we would all be sitting here right now the distros might be all more successful that possibly but like that that is one of those tools that that actually take the cloud native part and stick it over in the side for a second put a pen in it operating literally anything these days without without some sort of CI system is insane and irresponsible right like it it doesn't matter whether you're doing turns out you can do CI on things that are not cloud native applications we install and test OpenStack 20,000 times a day and I will tell you right now it is not a cloud native application right it's one of the when we talked to customers about how to how they need to start going on a path to cloud native we talked to them first about taking their legacy applications that they may or may not ever move there and say get control of that first implement some predictability in the build and test deployment capabilities of it and start there that way you can first of all get your feet wet with it but but more importantly get some predictability and control I think that without that that's where the kind of hero hero aspect of software development comes in that is the person who's coded themselves into job security I think I think one of the big shifts to you know whatever you're doing if you're making a digital transformation to agile IT DevOps cloud native whatever the tech is only a big small part of it a lot of it's the process inside an enterprise one of the most dysfunctional stories I came across at a customer in last few years was talking to them about puppet content they're like well it's just too slow for us to adopt modules from the forge and I was like that's pretty weird because you just kind of type puppet module install and I like oh we can't do that we've got a security policy that is all users and groups must be represented in a single configuration file so we have to take all of this upstream content all these other people have written modified pull all the user groups out of it into a single file that takes us about three weeks then a new versions come out so we spend another week or two catching up to it and then we deploy it and I was like why are you doing that and the security guy in the corners just like because that's our policy and and that's the sort of crap that actually I think is slowing people down actually it's your work and manage traditional enterprise software in a pretty traditional way rethink a lot of your policies and processes around them to be sort of sane and relevant to the actual year you're living in and achieve huge benefits well one of the big challenges we have when talking to companies is how do they take their existing development infrastructure management model and break down the silos and the processes that exist between them to create more holistic teams that can do all the development changes necessary within one sprint in order to get something done but when you have issues like that it works against it so when you've got multiple generations of itil rules lawyers in your organization yeah that's your biggest problem Jonathan Bryce has a in one of the talks he gives around the places a story that I'm gonna paraphrase so it's gonna be all wrong so sorry Jonathan but he's talking about a you know company that was adopting adopting open-sac moving to cloud and and beforehand they're they because they they had problem right like they it took them I think 38 days to roll out a new change right and that was they were not happy with that as a business and so they they implemented cloud and and and as as a result they were able to roll out new changes in 37 days and they were they were they were less than pleased with the results of their of their journey to the cloud right they're like why did not fix it it's because they hadn't changed any of their process their business process and thinking so they still had people go through paper requisition forms to be able to make the API call to the cloud to spend up a VM right and and and so it it was really the so having cloud there did allow them to adopt some things that eventually to allow them to speed up the way they were doing things but one of the real wins I think actually in this case having cloud there allowed them to not use their technology stack as a scapegoat for their you know oh we have old these old bare metal machines and they won't they won't allow us to do this is actually their processes were killing them right and and in this case it put them into stark relief for like oh well now we're on cloud and it still sucks maybe we have to look at ourselves in the mirror and and decide that that possibly filling out paper requisition forms and handing them to the one person who takes them upstairs and his secretary hands them to the other person and you know and you can do all of this without actually going to the cloud you know it like you can sit down and take the lessons of a 12-factor app yeah writing micro services having a database service rather than using RDS and achieve all of these benefits like the cloud magical it just forces constraints so is the right way to see this as active forces infrastructure changes forces organizational changes or is it some I think it's all the business is failing at actually delivering value to people yeah and so take a systems thinking approach to the whole thing yeah and whether that pressure from your org is coming from the app developers whether it's coming from your security team who are just going seriously if I stare at one more log file as my job I'm going to shoot myself or whether it's your operations people going my pager hasn't stopped buzzing for three weeks like someone somewhere is going to start screaming and going this isn't working yeah and someone at the top level is going to go we're not making money and shipping things fast yeah I think I think the challenge in in trying to fix the pieces like treat cloud like a magic pill and just take it and you're going to fix your problem and then you find that there's other aspects to it you know starting instead and saying what's the shortest path for a change a new feature or change to my configuration to get that from inception all the way through to production modeling what that shortest path looks like and then determining what's the development process the testing deployment the infrastructure changes and how how is that going to work and then removing all those barriers and restructuring it the problem is that in most enterprises people's jobs are based upon yep the fact that they run a gigantic organization it's responsible for this process and they're not always willing participants yeah this is to segue to your earlier sort of seemingly unrelated comments about the Cubs like there's a reason why all of the DevOps folks end up returning to lean manufacturing loon met Lane management Toyota Carter value stream mapping like the manufacturing industries sold this a while ago and they went through this process of whole bunches of jobs went away we adopted automation and we worked out how do we actually shift value quickly like the process you described is the value stream mapping from the 70s yeah and it turns out like this is one of the reasons that I think that that CI CD things are so essential whether you're doing cloud native apps or not like they're applicable to they can be applicable to anything and a lot of that winds up being replace repetitive human tasks with automation if it's a thing that I can't do better with creative thought right then it is not a valuable task for me to do as a human as a human the thing that I can do that a computer can't do is is is intuition and creativity right a computer can repeat the same task consistently right it will always do it the same way if your computer doesn't always do it the same way then then you as the human have have broken the computer in some horrible horrible way but but you can do that so all of those things were like that well our processes we we we cut the the pre-release and then we handed a QA who has a thousand people who all run through these manual test scripts where they check something manually to determine if it's if it's right and the reason people do that is that they want to to instill a confidence that when you when you deploy this change that it's going to be good but but even then even with all of those humans doing all those things you have to take human fallibility into account and so people are still scared they're still worried so you introduce more process more level so you you go through one level of human testing and then you put it into acceptance testing and then you put it into and you're like why in the what in the world are you doing there that you couldn't script and automate and either these can be you could do all of this for anything that is on the computer right I think some of the challenges in this area is it's only until recently that a lot of hardware had the richness of API's that could allow you to automate it as well as some tools to support the processes so either you were forced to build it on your own remember the old days of building the these different tools that you could use to drive a lot of stuff and you turn into running curl and a billion expect scripts SSH into things yeah you turn your you turn into a tool development team I mean you know think about the you know those days and so I think as vendors have have started making serious products in these spaces and the ability to interact in a rich way with some of the with hardware devices as well as different software layers I think the ability to automate this and make it predictable and reliable is yeah I mean I think it's here in any ways I think the biggest change has been we've somewhat democratized automation yeah we and I don't mean just in the infrastructure as code ansible puppet chef space I mean just sort of all over the place we've actually got API's that are accessible we have you were hacking crap together yeah well and like so we we run a wide variety of things some of them are what you might term I would I would turn cloud native that they don't actually fit strictly in a 12 factor application but turns out that's that's that's a concept not a not a prescriptive set of guidelines but some some things that are there were definitely cloud native visa wrote them specifically on top of cloud API so that by that all the way to things that are you know things running in Java war files right in whatever and even those are made better by us having the cloud available because it's really easy for us to spin up a second VM try out an upgrade and if it and it fails just delete that VM and start over like we can we can do some validation even if it's a manual validation is we haven't had the time to fully automate that we can do a couple of trial runs with almost no cost compared to the I have this one machine if I wanted to do a trial run of deploying it to a to a machine before I did my upgrade here I'd have to have a whole other machine right which is like twice the cost and now you've got to convince finance that you want to double the cost of your thing for a machine you're going to use once every three months and they go nope so it's great like that's a that's a good point because yesterday when they were talking about at the keynote they had a press conference offering and almost everyone in that this stuff folks who talked said that they have three distinct environments one for like kicking the tires one for testing patches and then the production environment and it comes to open stacking they're still doing this isn't that some kind of a silly thing to do that you have three environments and what if your processes are the same and you're actually making those consistent I think that speaking to the fear point you raised earlier there are still humans interacting with these systems and people are afraid of touching production and you will actually get more innovation in your company if you create these environments where people can play without fear and they can be configured exactly the same way as production you can push all your changes they're exactly the same way but when it comes to you know a new employee who's only been there three weeks they're like well I have an idea I will try it out but if they're going to try it out in production they might not yeah so we've we've got a so the there's a the team I work on wrote this tool called Zool which I'll plug right now just because it's fun because I'm up on here and stage and I can but but it's the thing we use it for opensack development right and and it's it one of the things that it allows us to do is this thing we refer to as gating right which which basically means it's it's not gonna land in the thing it's gonna go to production until it's like it's physically there's a the computer is going to prevent it from merging if it doesn't pass all the tests of course that that's only as good as the tests are right but but it gives you the mechanism to put things in place that that allow you to have that freedom I can I can push up a patch and and have more confidence that it like so it like even in a femoral we spin up a a if you have the automation to be able to do a deployment and an upgrade in a in a in a sort of throwaway environment then you can script you know sort of sort of as we do hey I just I just submitted a patch for review hasn't even been code reviewed yet but we'll we'll spin up some machines and deploy it and and do an upgrade from the current version that's in that's in production and all of those things and then report on on that and then when somebody actually reviews it we'll do all that again just to make sure that nothing's changed and things broken so you is the reviewer can as the human reviewer can focus on is this a good idea right is this is this a good thought not is this going to break production because you've got you've got automatic confidence inducing things that are that are there that the developer doesn't have to you know so if your your path involves three three environments and you can repeatedly do that that's great there's there's a theoretical path that you can get to where you have one environment combined with a an infinite number of of copies of production that computers manage for you as needed right so you don't have you don't necessarily have to have a static copy of of thing you you have the the because we have infrastructure as code you have the ability to replicate production and especially if you combine it with development practice like feature flags and dark features all of those things I mean I think the amazing thing again about what you just said is none of this is rocket science like you should do it the people who you know was like how do I do DevOps it's like well do you have any good developers mm-hmm how do they manage their practices software engineering worked most of this crap out quite a while ago yeah because it learned the lessons from manufacturing yeah I think in many ways you could say DevOps is operations and infrastructure people finally waking up and going you know what these people we interact with they've solved a whole bunch of problems yeah that we should just solve the same way I think yeah that's I was gonna say an interesting example something very similar what you're describing we were working with an insurance company who were attempting to blur the lines between those different environments and they stood up one cloud foundry environment and used basically pipelines for provisioning infrastructure and containers within it basically where the they had they used the routing basically into that into the instances into to manage what was production and not production so all the workloads internally could be or we're just running some version of it and what however it was however you mapped your the URL into it became production and how whatever you attached you from a data source perspective but they basically shared the physical infrastructure as it you know one big set of compute resources and I think they learned a lot that that there's less complexity when you can do it that way but you have to be able to manage be conscious of the risk that you're not you know which I think speaks exactly to the premise of the abstract that we're sort of finding ourselves disagreeing on you can have a super reliable hardware infrastructure layer and as more and more things just become either software or can just be treated like software you have all this flexibility to sort of create those sort of segmented different areas of quality or data protection or how you want to trade it yeah so that's a good question as a good point like to open it up for questions if anyone has any questions to ask we are coming up on like the remaining 10 minutes or so anyone questions we're willing to babble about any topic yeah open-ended anything doesn't have to be about DevOps or infrastructure can tell you about some great coffee shops in Barcelona it's always the cubs if anyone is feeling lazy they can just yell and we can repeat or we could just all yell so I recently had to talk some executives down from having a dashboard to monitor the CICD implementation they were hoping to push through collectively for an entire org that shall remain aimless to look at my badge and one of the things that I tried to explain to them when they were talking through the metrics that they wanted to see in order to assess whether they were successful was that the things that they were privileging might cause fear in the developers if they went red and and create behavior and reactionary behavior in the developers that actually went against the main principles of CICD I was wondering if you had any great metrics that you could recommend for organizations to look at that wouldn't inspire fear I think you probably have the right metrics but there's a cultural problem there like it's the same thing as when agile software development happened if you're moving in smaller chunks more are going to fail and if your organization has you know this fear of if it ever goes red we're all doomed like that's the problem like because the whole point of taking agile small chunks moving in a way so you can course correct more frequently is you're going to fail more often but your overall velocity is much much higher so there's sort of a cultural gap there and I totally understand like in many companies if you tell all the developers hey by the way if you ever break the build the CEO will see that in their office you reduce the cost of failing yeah yeah that's exactly a question of companies looking at risk in a different way or taking risks in a different or CYA I liked your reference back to lean manufacturing which is how quickly can I validate some hypothesis for my business in a way that where my infrastructure and my applications there's the least amount of work I need to do in order to test this yeah and I think that's really ultimately how you show value requires you to change the way you think yeah like a good example of this I've been involved in in several arguments about deploying OpenStack in a continuously delivered manner from master as opposed to deploying stable releases of OpenStack and in general the conversation goes a little bit like this I wanted to play the stable release because I want to deploy the stable software and I want to minimize my risk and I'm like okay well the thing that you're doing is you're setting yourself up for a six months worth of change event every six months because we have a six month release cycle so while I can see that the word stable might make you think that you're that you're minimizing your risk you're actually increasing it because you've increased the amount of risk you're taking at any one given point in time whereas if you set your organization you're thinking up so that you're deploying ten times a day then think about how small the risk of each of those deployments is and and what you're actually doing there is you're minimizing the risk into into into manageable bite size chunks and this is exactly the thing it's that it's the same and these are all of these conversations have been with companies who have theoretically adopted agile right but they haven't adopted agile because all they've done is their engineering teams have adopted agile and their executives are still are still the business is not adopting so risk is just one side of that like just to jump in like every time you're taking that risk is a learning opportunity yeah and you can learn an awful lot from only deploying once every six months sure but you're learning it all at once yeah exactly I think to come back to the original question get if you've got that sort of cultural fear work out something that everyone agrees on measures quality because who cares what happens in the pipeline yeah like really like if the pipelines read three quarters of the time and in the end it means you're shipping every three days and the actual overall quality of whatever it is you're creating is better like that's the metric the high-level management should be caring about in a sense they should be happy if they're seeing failures because they're like oh people are trying things I think change is actually happening through the org and we're not going to increase quality without creating change so focus less on on failures in the process and more in whether it meets the business objectives yeah and I'd argue it's not even a failure in the process it's like anyone who's been through science you know there's this whole agent of change here to think about this differently I mean you talked about the engineering teams having implemented agile but the infrastructure side is still in different way oh no it's this it's the executives that are that are that are all almost always the problem because everybody likes to blame the engineers because the engineers don't have any cultural or political power inside of an organization so really what I'm now advocating for is is a communist overthrow of power to the farmers so that not co-syndicalist yeah narco-syndicalist approach to software but but quite honestly a lot of this problem is is that you have these organizations that are trying to go through these transformations and none of them ever think to transform their their old thinking upper executive set so you have you have maybe they hired a whole bunch of you know hot new people down in the in the ranks to do stuff and then and then the folks sitting on top of that are the people who have been there for forever and and that doesn't mean that a person who's been there forever has to necessarily there's a bunch of people who are turns out that the myth that all of the 20 year olds know more than the 50 year olds is quite a myth but but you have to be able to assess and judge whether whether somebody is is the the the organization is embracing the change holistically and if if the if the change is stopping kind of at some executive level then there's an executive problem it's not a problem the engineering team isn't implementing it correctly right like that's now how you implement that changes is a very good question and it sort of depends on how your executive compensation structure works and and how involved the people that are in charge I mean they're ultimately responsible but again I'd sort of take challenge with the question like who is the agent of change it depends yeah you know there are some organizations where I've seen a developer the innovator has built a thing you know and then everyone goes wow that thing is really cool I mean look at you know what's the classic innovation story with 3m you know some guy was mucking around with glue and a bunch of pieces of paper and went oh wow this could make these little post-it notes yeah and that's like this billion-dollar business for them and they made sticky tape and so let me qualify my question the agent of change when it so you mentioned the executives but who convinces the executives to change their thinking I mean it's I think it's usually CIO magazine yeah yeah or maybe the United brochure and I think it's actually section we need we need more brochures in the back of seatback pockets and in first class oh I just I just go shut the me as I as I board the plane yeah I really enjoy when there's it when there's an ad for for private jets in and I'm sitting in an economy in a middle seat and there's a private jet add to my I can't even get up in the first pass you're trying to sell me on a private jet what's wrong with you I think if you had to point a finger at someone I think in a lot of organizations is probably the CIO or the CTO you know thinking back about companies I've worked for where there's basically a revolving door at that level because they come in with a big plan to make changes to affect the business and they're approaching it from a very traditional model and the reality of it is it's really hard to do and so they you know leave after a few years because they weren't successful they didn't know how to measure they didn't know how to they're they didn't know how to sell it to their leadership and I mean I think that they're ultimately the ones because the the whole the business basically how the business is run below that and how they how they communicate the ability of technology back to the lines of business I think it's really sits at that level but it's a difficult place for them to be in and they need people to support them and I think the pressure is coming from an interesting placement one one of the places I'm seeing for better or for worse as the buzzword of DevOps like makes its way through the C level suite through the through the C suite we've got people like Ernst and Young sending out literally pamphlets to board members of companies going your CIO is now your chief innovation officer if they don't have a DevOps strategy you're all doomed and so no literally then you're having the board meetings where you've got board members who haven't some of them haven't run companies for years will suddenly go well so what about this DevOps thing what's your DevOps strategy and the CIOs starts freaking out in the board meeting and then goes to their VP or director of technology and goes seriously we need to rub some DevOps on everything yeah and like that's a pretty clueless and sort of horrible dysfunctional anti-pattern but it's at least giving incentive to the developers the operations the infrastructure folks to go you've got a mandate for change and in some ways they get to educate up yeah there's there's also I think similar to that or in contract or in in terms with that is the the various sort of business finance side of things right because if there's if there's a more traditional outlook on on how you finance the lines of business right how how you how you hand up that the CIO can have all the DevOps strategy in the world they want but if if finance comes and says that well we've got these and HR says we've got these really strict you know tiers of guidelines of of what you can what who you can hire and where and how and all of that type stuff and then all of a sudden the CIOs like well I was gonna do DevOps but the only people that I can afford are these guys that are they're standing out back of the gas station and they told me they can they can do some DevOps for me for like $20 and that's like you're this is why I think it's important to actually remember one of the original things of DevOps is measurement yeah like I was really horrified when we hit this certain point in doing the DevOps survey where we started going well you know statistically we can show these companies make more money their stock prices are higher they're achieving their business goals more regularly and suddenly we're meeting with IT directors who are like my CFO insists that we investigate this infrastructure as code thing you're like that's kind of interesting yeah and so we've got to we've got to talk about the stuff we do they've optimized around their current yeah but there's and there's there's two there's there's a there's a couple different ways that you the make more more money of course I mean there's many but but there's there's there's cutting costs and there's there's increasing revenue right there's doing more or or paying less to do it and and one of the one of the things that I keep seeing in places is the folks hearing DevOps and thinking I get to pay less for all of the things that I want to do and I'm like it's not necessarily going to work out that way but it may be is that if you that you might get more for the amount of money that you were paying or you made just you actually made pay the exact same get the exact same but not lose in the marketplace like that also may be that like don't expect magical ponies and rainbows to dance out of all the developers you know faces all of a sudden this really hilarious definition there's a hilarious definition DevOps I'm gonna repeat for at least the next few weeks that someone told me which was DevOps for developers is like we don't need operations but for operations people it's all we get to do some development yeah well that's yeah that's a great so we are out of time but before we before we leave for the day we have a raffle and if you have a couple of more minutes I'd love to have you guys sort of looking at it from your side you know what you would present as one big case for you know changing the manner in which companies think of this you should take a systems thinking approach to your whole business and probably do something like value string mapping to work out what actually delivers value and how much it costs awesome yeah I think that is that's an approach that we advocate a lot with customers I think that that you also need to look at what's the right level of integration you need from a technology standpoint some customers are happy to be able to put the pieces together because it need to be very flexible and others need a more integrated solution and you know I think figuring out where your company is at I think is important demand API some your vendors yeah yeah I think I agree with absolutely both of those things I think that that you've got to you've got to look at the whole the whole business it can't just be can't just be I'm gonna I'm gonna dump more stuff on over on the more requirements on the on the tech side without without giving more resources like you and without changing how I do things over over here in the in the business you know business upside of things you got to got to think holistically and look at the whole thing figure out where things are breaking down you know if your security compliance stuff is taking you you know months to get through turns out there's people who are doing that pretty quickly and so it you know it maybe that you need help figuring that out it you know it everybody is working through this so there's plenty of people who can who can be helpful in in those endeavors but but it's not it's not ever gonna be just a one a one trick pony or a one shot fix you've got to be willing to to look from the from the very top from the C-suite all the way down to the thing and figure out what's what's working and not wondering and how can I measure it like how can I measure yeah not just how can I measure the engineers productivity how can I manage the finances productivity yeah and not just from a what's the bottom line because obviously that's that's everybody's productivity but like how can I manage finances impact on on engineering so that that's actually good for that dashboard maybe a way to combat the engineer fear is go we're putting that dashboard up the other one we're gonna put into is time from filing expense report to engineer getting paid yes like yes something like that show we're gonna measure all bits of the business we measure all the people and that's that's exactly right put the put the put the heat on the on them so now for all the patient listeners you have a raffle who wants to build the honors I thought there would be more of you 293 who's the lucky winner 293