 Well, hello everybody. Wow, that's loud. It's like the voice of a demigod. Anyways, hi, I'm Michael Cotay. This is a session when is the DevOps unicorn gonna sprout wings and fly? And as you can see, perhaps you can't, but I'm from Austin and we've got an interesting little DevOps thing going on there and we've been studying and looking at DevOps for quite some time now. And what I wanted to do in this talk is go over the question. So if you're not like Netflix or CERN or all these other people who are sort of like special unicorns in their own right and you're sort of in the mainstream world and you're interested in applying DevOps in your normal run of the mill pay the bills job, how's that working out? Like how's mainstream DevOps going? And so that's what I'm gonna go over here. And I think it's especially applicable for the OpenStack Summit crowd and conference because my theory which is more or less anecdotally proven out is that many of the reasons that you build a cloud is to run custom written applications on top of it, which as we'll get into sort of begs the question of doing more DevOps if you will. So it's sort of one of the practices one might be deploying up in the stratosphere of the clouds you guys are building to mix metaphors painfully. So before that, it's always good to establish some credibility before you give a talk. I'm an analyst with 451 Research. So we're about a 300 or so person analyst company. You can kind of see our stats there. We do all sorts of things. We cover vendors behind the paywall that we have with reports, go over practices, what people are doing, talk with the investment community and end users as well. Just advising them as an analyst will do about what they should be doing with their IT, whether they wanna sell it by it or invest in it. And I started working there in September and as my quick little bio, that's me up there. As it goes over, I actually have been an analyst several times. I used to work in another firm called Red Monk and in between Red Monk and 451, I worked at a little firm in Round Rock called Dell. Not so little I guess. And I worked there in corporate strategy starting up the software group and doing M&A specifically on software and cloud, which gave me an interesting viewpoint sort of in the trenches about what's going on there. And at 451, I head up the infrastructure software practice where we stutter, I guess you could call it on-premise software that's infrastructure-based, as the name would imply. So systems management, cloud software, application development, things like DevOps if you will. And back when I did real work, I did a lot of software development at fun places like BMC and an online banking company and lots of absurdly failed startups. So getting into the meat of it, now that I've established my credibility, here's a report that we did, the first rev of the DevOps study. So like I was saying, the first thing in September when I came into 451, I wanted to get a handle on what was happening in the DevOps world because it's something I didn't really find again for a mainstream vantage point too much of in the analyst community and there's plenty of blogs and talks about it, but I wanted to do a nice study of it. So we got some people who were interested in finding out more about what the early mainstream DevOps market is and we did a study of 200 people if you will. We filtered down from 500 to 200 and asked them a series of questions. Essentially getting at what's happening, what's the baseline there and the buying behavior that you have. What does it look like if you're not one of these Uber unicorn DevOps people if you will? And so the first thing, other than showing you a fancy screenshot of a PDF here, what I wanted to point out is, whenever you do a survey, you make some compromises and you can't have too much nuance, otherwise you'll never sort of launch. So if you can read that fine print up there and by fine I mean small, not fantastic, you'll see that we've kind of like settled on what might be a slightly controversial definition of DevOps and that is, I pretty much reduced it down to you're interested in releasing software into production as frequently as possible, right? And so this goes back to the original pre-DevOps velocity thing with I think it was Spock and Scotty who were presenting and they were going over how Flickr releases 10 times a day and how they enable that essentially. And so again, it's sort of like, how do you achieve that goal? And you know, a lot of, and the way technically it seems like people achieve it is they use cloud technologies and lots of practices from the cloud world. Not only cloud as a platform, but lots of the new interesting tools that are being used in those contexts. So we filtered down those 500 people to about 200 people who seemed to be sort of in the mainstream. So there was no one from the technology world. They were all from many other industries, if you will. And who either kind of self-identified as doing DevOps, you know, they knew how to correctly camel case it or they sounded like someone who like was DevOps minded. Like they were deploying to cloud first. They were doing applications on a rapid cycle. So we very much so selected people who seemed to fit this idea of what DevOps was. So before I get into the sort of details with a distracting tour through macro things of why you should care about all this, I always like to start presentations with the conclusions, if you will, or the next steps so you can be actionable. And I'll go over these again at the end so you don't need to memorize them or take a picture of them. I guess you can. You can take another picture. I think I changed the title on the last slide. But just to summarize so you can leave or if you need to use a restroom or you want to polish off some more fruit juice or whatever you got going on. I'll go over what, you know, I think the takeaway should be. And keep these in mind as I'm talking and you know, during the Q and A you can tell me that I was full of crap when I had these conclusions if I don't sort of prove them out. So the first one is if you want to do DevOps, right? And you want to move as an organization into releasing your code into production more frequently. You want to be a DevOps person, if you will. There's sort of three buckets of things to think about. And I'll go over these in more detail at the end so I'll be very, very quicker. But first as with any IT thing it's good to focus on planning. That is you want to think about I've got all these hundreds of applications because I'm not like a one application person like a Netflix or a Facebook or all these other people who actually have a very small amount of application to support versus like a bank. So segment out what the workloads are and pick ones that you'll be successful with early on to move, right? Like don't just move everything. And definitely, you know, you don't want to move your SharePoint cluster into a DevOps situation. Like I don't think that makes sense. And you know, the last point is a key one for I find a lot of cloud things but cloud DevOps oriented things in particular is find a green field application, something new. Don't find a brown field application something old because it'll be a lot easier to build from the ground up if you will. And then of course, once you've kind of done your baby steps it's nice to move into more advanced things and so forth and so on. And so when you are going from, I don't know, crawling to walking, your baby steps, how do you bootstrap yourself? And in a business context, I think this first point is key and that's what part of why as we get into the donut pie charts we're doing this base lining is benchmark yourself, right? Like you want to know how good you are currently so that when you go through all this hassle and change you can figure out if you've improved or declined. And if you don't like know how to currently rate yourself then you should focus on that because you could be wasting all sorts of time on new shiny things. And as is often the case, especially in this community, right? Like I think you'll see the timing is that it's actually not, you're not like late to doing DevOps but now's a good time to start doing POCs and labs and screwing around with it to learn about it to bootstrap yourself into it. And then as we'll get into, I focus a lot on the DevOps tool chain. And there was a great presentation earlier today from Lee Thompson about the DevOps tool chain if you want to kind of dig into what the specifics there. But I spend a lot of time talking about technology but the DevOps community as a whole is very obsessed with culture and process and like all these things like people. And I talk a little bit about that but because there's so much saturation of that I didn't go over it. But in fact, it warrants a third column here. As I like to call it, hell is other people, right? So unless you're a solo person you're gonna have to deal with other people and how to work with them. And the study that we did kind of pans out that like as with all technology changes much of your time is gonna be spent on process and people and things like that. So, you know, the juice bar is out there if you're thirsty. So, you know, I'll give you some little commentary. I always enjoy when some sort of professional expert tries to, you know, open the kimono as it were or the shirt and sort of give you some secrets of their trade. So the first thing is as an analyst you're always trying to come up with some sort of cheesy framing something that you're known for, some word. I'll give you like a really embarrassing story from me of trying to do that unintentionally. Back in like 2007, you know, there's the big four of systems management. And there were these four startups who were trying to disrupt systems management. And I came up as someone down here knows the little four. Now what was terrible about it is one of them was really not applicable. So I just proved myself kind of an idiot. But you know, it was a cool name, little four. And some people like remember that and it was a good framing for like Xenos Groundwork Hyperic and OpenQRM. I'll let you figure out which one the one was a Bozo one to put in there. And you know, it was nice because now you had a good opposition between the two of them. And you know, there's other things like, you know, service-oriented applications, citizen developer. We've got a great phrase of our own best execution venue. That's all about where you place your workloads. Kind of a rethinking and rephrasing of capacity management and planning for a cloud world. So allow me to come up with some cheesy things. So when I look at over the next 10 years, I think probably what's gonna happen is there's a lot of software rewriting ahead of us, right? We've got mobile apps, we've got this cloud stuff, like, and I don't know about you, but like I said, I worked at that little round rock company and man, enterprise software is awful, right? Like people need to come in and rewrite the HR apps, like all that stuff, there's so much. Like, you know, a good example that all of you guys will understand is like, not to get ahead of ourselves, we gotta rewrite the software in this too. But like, we don't even have version control in office. Like, that's how far behind we are, right? Like the idea that like, you should be using a file name as a white collar worker to encode your, what version you're working on is like pervasive in the enterprise software stack, right? So not only are there new form factors, like mobile and delivering on cloud, but just the software just desperately needs to be updated. You know, there's lots of flex apps out there still from the last time we tried to do this and those are gonna need to migrate as well. So we've got this poll, right? We're gonna be rewriting a lot of software. Things are gonna be great because it's gonna be new software. And anytime you rewrite new software, as Y2K people know and going from like, you know, mini computer to client server and internet, like that requires a lot of new tools and practices and methodologies and all sorts of exciting stuff's gonna happen. So the big disruptor there, and that happens nowadays and here we are to, you know, the open stack summit is sort of cloud, right? So in thinking about, strategically thinking about what we're gonna be doing during this great rewrite, you know, the question becomes, so if I'm in the IT industry, I'm a vendor, I consume IT or I just sort of like, whatever it is I do, I kind of flit around the edges and take pot shots and comment on stuff. Like I've got to kind of know the raw material I'm gonna be dealing with in this new environment. So I'm not really an application person. I don't care about applications so much. I like, I used to like writing applications, but so, you know, applications, that's the thing. But nevermind that. Let's take that as software as a service, right? Let's just assume that all the applications that you use are the majority of them are gonna move to being delivered through a URL. So then you start to think, all right, so if there's not really any on-premise package software, what's the whole ecosystem of stuff that that like drags away from it, right? System integrators doing hardware, networking, like you don't really have all that stuff to mess with. So, you know, the way that I think of this question is like, if you take IT as you know it and you subtract out SAS, what does that leave over? And that means that if you're not gonna be a SAS vendor, someone who cares about SAS, whatever that what is, is what you've got is your raw materials to deal with. So, you can imagine for me, this is kind of an important interesting question as my friend Israel retweeted here. And I think one person, I think it might have been John Willis there, he said, you know, IT minus IT equals IT or something like that. Is it, you know, that's fair, computers, right? But anyways, I always like to break the rule and put a lot of text on slides. So here's a bunch of text on a slide, and that's supposed to do, so I've unlocked that achievement yet again. I'm gonna get sort of like the third round of it in my presentation square app. But thinking through the whole thing of IT minus SAS equals what? And one of the reports I wrote about seemingly unrelated at Lassian down here, you know, this paragraph kind of nets it out. And that is, so if you subtract out SAS, it sort of leaves like a couple of workloads, if you will, a couple of things that IT does. Well, you gotta keep the network up, which is thrilling, right? So I'm not really interested in that. You gotta manage desktops equally thrilling, right? You know, even if it's BYOD whatever you're managing your white collar workers and your workers in general accessing your computational resources. You know, we haven't gotten to the point yet where like you're expected to buy your own car to drive for work metaphorically. Like you're not quite expected to provide all your own IT, which is another discussion that's confusing. And then there's things like we could bucket it as analysis and data. You've got like HPC, business intelligence, big data, right? So all of that is kind of like customized stuff that you might buy. You might run it in the cloud or on-premise or off-premise, but it's sort of like special sauce that you're putting into. And then it seems like the bulk of what's left over in the IT minus SAS equals what equation is basically custom software development, writing your own applications, right? So if you're not babysitting, what's the pet of your ERP install and your sort of collaboration package software, like all that stuff consumes a lot of time, like you're like, oh, I just go to a URL now. I don't need to do all that. And then so you've got all this excess time. And as a company, you could, I guess, fire all those people if you were like in a bad mood that day. Or you might start thinking about, here's the way I can use those IT resources to do something different, which I think is largely, I hope, is largely going to be driven by doing custom software development. So that's sort of the theory. And then looking at sort of the forward macro trends, if you will, I like to say macro trends. It makes me sound really smart and fancy. You know, if you look across lots of verticals, I don't, as I disclaim down here, I don't have the white color tool chain, as I like to call it spoken to, but you look at all the industries and they're sort of like this ongoing injection of IT and custom written software to make things better, right? So, you know, the canonical case is, you know, it used to be, you know, you yell at each other of creating your orange juice commodities and everything here on the stock exchange or commodity exchange or wherever you might be exchanging. But nowadays, you can like rent out the floor to have some ballerinas or like Captain America come. It's like a total marketing thing, right? Like, like business doesn't actually happen there because they're computers, right? Like, all these computers and software developers just automated the crap out of it and, you know, now they're doing like flash trading and probably ripping us all off, but, you know, they're just computers. It's like progress. And, you know, in the retail space, we used to have these things called knuckle-draggers. Like, every now and then you get in a taxi cab and the guy's like system's not working and he's got to use a pin to like do this carbon copy thing still. But for the most part, you have things like Square and like highly automated, automated is the wrong word, but highly computerized ways of doing retail, which is even better than the POS systems that were out there. And, you know, when something like this comes out and starts to dominate, like down in Austin, it's even gotten to the point where there's sort of like peak square, if you like. Like, I'll go into shops often and they'll have like that square sticker on the door, but they're not using square anymore. So they've already been through using it and been onto something better, which is kind of interesting. But the point is a bunch of developers, right, like came together, like they wrote some software, right, that does all this. Like, it's all like software developers writing code instead of worrying about managing other stuff. And you see this pervasive through retail, right? Like you hear all the stories about like target knows when you're pregnant or when you ate a bad oyster the night before. And like, you know, that's again, that's basically developers, you know, data scientists or whatever you wanna call them, programming and doing custom software development. And then the medical area, right? Like, I mean, I don't know about, I used to have to buy my own health insurance, so I have like really mixed feelings about the healthcare system. But you know, you got like all this paperwork, like it's crazy, it's absurd. Like, and they ask you for your phone number five times and you know, you would like there to be some computers involved where like, I don't know, you could give them a USB stick to give you a copy of your records. Like, simple stuff, like version control and word. Like, it's not rocket science. And also, because at least in the US, I don't know how it is in the rest of the world, but there's mandates to have more data-driven ways of billing and paying for things. So essentially there's, again, this injection of the need for a lot of IT and custom development in the healthcare. So you can have like, instead of this sort of like person quarantining you and like wearing gloves, look at that nice handsome doctor with an iPad. He's like, you know, using computers to make your experience so, she looks so happy, right? Whoever's in this room, probably not happy, not happy at all, but down here, because computers, they're great. And then in the consumer space, it's hard to come up with an example of consumer things. So it's so pervasive, but again, it's worth thinking about how, what is the frequent, there are more companies that are not technology companies doing custom software development. And you see that, of course, it occurs to me that I used Google as an example here, but this is a guy that I do a podcast with, and he's, he gets written up all the time as like the most quantified man in the world, right? So he's got all these sensors that he wears and he tracks everything. And kind of the end result is in the consumer space, he used to be, you know, well-fed, right? Like a good looking guy there. And he started tracking himself and got some hair gel and like he wears like Google glasses and look, look how handsome he is now, right? And again, it's like computers, like all of these sensors and things, it's not only the hardware, but some developers got together and they're like, how can we get Chris Dancy to look that good, right? Let's write some code. And like he's got all these devices with code scurrying around. So, you know, and then there's like, you know, Nike fuel bands and on and on. So think about all the industries that are out there if they just had a team of developers that could like write some software that would like make our lives better, right? And again, you see that across verticals that there's the potential for that. So one of the big macro things, and then I'll finally get out of this macro rut, if you will, is, you know, cloud is clearly both public and private and all the permutations. It's increasingly in this environment where you wanna have as a business, people writing software that kind of mediates your relationship more with your customer through software rather than people, because who wants to deal with people? You know, it's much better to deal with an app than a person. Like, you're probably gonna use a cloud as a way to deliver it, right? So cloud is kind of like the environment that all of this is existing in, right? It's not like, I'm not gonna show you some market sizing for the UNIX market. Like, that's not gonna make my friend Chris healthier, right? Like, thank God UNIX saved me, right? It's all gonna be delivered on top of cloud things. So what's important is, and obviously you guys are involved in that operating in that, this is another analyst thing, like, it's one thing to be excited about a technology and shiny object stuff, like from my developer days. But basically, unless there's high growth and a lot of money, the rest of the world doesn't care, right? Like, there's got no interest in it. So what you wanna know is what you see in this chart. In the cloud world with a cloud environment, how much money is there? And is that money fast-growing, right? And you can read these figures. I've got two charts to show you as far as market sizing. And the one of them is the public cloud forecast that we do at 4.5.1. The next one will be the, let's call it the private cloud software, cloud-enabling technologies. Not running cloud, but spend about software to do cloud, whether it's private or public. And so why am I showing this to like, you know, a tech conference where people care about Python and not pesos and all of that, right? Like, I don't know who cares about pesos, dollars. You know, because if you're gonna go back, right? And you're like, hey, I wanna use software to make my life better. Like, I've heard all these people like are doing the software stuff. The first thing that you're gonna have to prove is that there's a lot of money in it, right? Like, whether you're an end user, whether you're a vendor, someone who wants to, you know, use cloud technologies, you wanna prove, hey, it's not going away, it's a serious thing, and it's a major part of the industry. And so these numbers like give you that coverage if you need. You know, you throw this stuff up on the wall and like, hey, look, it's real. It's not fantasy. So to that end, you know, the way we do our market sizing is basically it's a bottom's up approach. We call around and under NDA and, you know, we anonymize the data, we get revenue or we estimate revenues of companies that we think are in public cloud and we throw that up there. So, you know, your forecast will vary from analyst house to analyst house, but all you really need to know is look, it's going up. So we'll go to the next slide. And that's in billions, right? So there's billions and billions of dollars there. So this one is like what I find especially interesting because if we go to the previous one, right, like this is all public cloud. So we're tracking infrastructure as a service, platform as a service and infrastructure SaaS. We don't track SaaS like Salesforce or other things like that. It's all infrastructure stuff. And this is sort of things like service now and other SaaS infrastructure applications that are used to support infrastructure. And so I find this a lot more interesting than an aggregate cloud thing because an aggregate cloud thing has SaaS in it. But this is all the stuff you guys work on, right? Like infrastructure, not like applications. And again, even more so when you look at our cloud enabling technologies sizing, and these is actually very fresh from April. So not very many people have seen these numbers. So you guys are lucky. Essentially, what we have is automation and management which also includes platforms to some extent like the raw cloud platforms and then virtualization which includes, we're cleaning up our methodology here, but trust me, I know the companies we track in here and it's pretty good at representing private cloud software that you might buy to do private cloud things, whether it's the actual cloud platform itself, something like Chef or Puppet or an orchestration piece of software just up and down all the stuff that you would use for cloud. And again, really all you need to know is it's going up and it's in billions, right? So there's a whole lot of activity starting back in 2012 and like around 25 billion is not too much to sniff at. That's a good rate. So the point is that in this environment, right? Like if you want to start deploying things on cloud that's clearly the direction things are going and where there's lots of spend. And the other important thing is I don't have the number up here, but it's the growth, right? The rate at which this is growing. Like normal IT growth every year is it kind of tracks GDP to some extent. It's like, I don't know, two to 3%. It's pretty boring, right? It doesn't go up that much but these growths are always double digits, right? So there's lots of activity and people doing things here. So finally, to bore you with some more bar charts, you know, the juices down there as a reminder if you got bored and I already told you the conclusion. So if you're bored to death, now's your escape hatch time. There's another survey that we do from Changewave. The previous stuff was from our Infopro surveying and we asked people in a corporate context, what is your plan for public and private cloud usage? You know, you can see we've been doing it for many, many quarters. And here we include SAS. So it's a bit like overblown on that. But you can see a steady rise and a slight flattening if you will of people who are planning on using public and private cloud, which is great. I mean, this is a huge part of the market, right? So all of your peers are jumping off of the bridge, right? Like lots of people are doing it. Cloud's a real thing if you will. Now what I find especially interesting is like the private cloud tracking that we do, right? Because I actually make a joke about this and I've encountered this a few times since but like I don't think private SAS is real. So I assume this doesn't include SAS. I think by definition there is no private SAS. So that means this is pure infrastructure, right? In the private cloud area. And again, like there's a huge amount of people who are looking at private infrastructure, cloud infrastructure in companies out and using it. And I believe this is all North American as well because that's what you do. Anyways, and this also matches with lots of the other surveys that we do that increasingly there's more and more demand for cloud. So in that environment, right? So what are people doing with cloud? What workloads are they putting there? And this is something that all my friends and Twitter followers and people know I obsess over is like I'm not really interested in the raw cloud. Like what application are you running on top of it? What are you doing with it? And so it's nice to have this sort of data at our disposal. So here's another chart that we have that goes over what are you doing private cloud on premise manage in public and hybrid cloud with in broad buckets of workloads. And you can see that public cloud usage is still relatively small compared to the other numbers that you might add up. But it's interesting to see that people are doing lots of batch computing collaborative applications. You know, they're sort of business to business applications things here. And these are kind of the two confirming like anecdotes you always hear here that like our core applications, we would never move that to the cloud or like some cloud thing. So they're very much so want these things to be hybrid, if not private, if you will, they kind of, these core apps take up a lot of the cloud usage. And then there's sort of a minority bar down here of test dev, which happens quite frequently. But again, it's interesting to know like what people are actually using cloud for because that discussion I feel doesn't come up very much. And then just very briefly, you know, I mentioned mobile as like something that affects usage of DevOps and demand for cloud quite a bit. So as one more thing to hopefully arm you with the ability to go back and like work on fun stuff instead of whatever boring stuff you were beset with before this, you know, you can be like, we really need a mobile app, right? And so we also have the Yankee group here in 451. And one of the questions they had in a recent survey was like, so was it useful to do a mobile app? Was it valuable to your business after you did it? And sure enough it was, right? So if you add up the, basically, you know, rate on a scale of 10, one to 10, where 10 is the highest, the value of having done a mobile app. And if you add up, you see here, the seven and the six and the 10, nine and eight, the high and the medium to high, like everyone was like, yeah, it was really valuable. It's a good idea to do a mobile app. So, you know, that's a nice area to go explore. Like it's clear that there is return on doing mobile applications. And then to dig down into that a little bit, it's interesting to ask in the same survey. I mean, it's a relatively small sample set. So, you know, we got that going for us. But essentially, you know, what are your customers finding valuable that you do with a mobile app, right? Is it just like customer service support, actually transacting things? And you can see these slides on slide shares. You can dissect these bar graphs as much as you like. But again, this gives you an interesting roadmap that if you wanna start doing a mobile app, here are things that other companies say that customers are finding valuable, right? Starting off with just like getting information from the company, like letting them talk with you, so forth and so on. So, it's always interesting to know what your peers are doing so that you can plan out the work on your own. Because, you know, ultimately, if we go all the way back to the top, right? Like the idea is we're gonna have some teams of developers working on code that are gonna start making business more interesting and driving more, not only retention but growth in their business use. They don't have to focus on the package software on premise stuff anymore and they've got all this free time to write custom apps, essentially. So, you know, obviously you're gonna need DevOps for that, right? Like that's sort of the assumption that I have is you wanna build these custom apps, run them on a cloud. And we used to call it Agile and all sorts of stuff like that, but you're probably not gonna use CMM, right? Or some Prince or Corbett or some other word that's in all caps. Cobit, not Corbett, but we should come up with that one. So, you know, that kind of gets to the point of like, so, if there's all this potential, what does the mainstream DevOps market look like? Again, we know that all the typical examples are awesome and they're doing great stuff, but out in the normal world, right? Like out in the fat part of the country, the middle part, not physically, just large. Like, what are people doing? And so, this is some of the questions from the study that we had just to get a baseline and a sense of how things are going. So, the first question we ask is when you deploy your application, right? Like, where do you end up deploying it? And it's somewhat counterintuitive to what you would expect, but when you're in the trenches of these surveys, it matches up exactly with what you continually see, is that people don't really do a lot of public cloud, as much, pure public cloud, if you will. Instead, they do a bunch of hybrid cloud and private cloud, essentially, if you add all this up when they deploy their applications, which is interesting, right? So, that means that at least amongst your peer group, if you consider yourself normal instead of extraordinary, if you will, or unicorny, that you're probably gonna be doing some private cloud deploys, if you will. And if you're a vendor, it means that you definitely want to service the private cloud market and not just the public cloud market exclusively. And it's also an interesting commentary on how far we are in sort of like cloud taking over, right? There's still lots of private cloud amongst this mainstream DevOps world. So, the next question we asked, again, the premise of DevOps here was that you are deploying to production frequently, right? So, the baseline question is, so, how frequently are you deploying to production? This is one of the nicer findings, is that, as you can see, adding this up, like, there is actually a lot of people who at least can deploy every 30 days. Now, we didn't ask them, are you deploying a bug fix or something wrong? We just asked, how often you update production? We'll get some more refinement on that when we do it again, but I would say this is extremely encouraging, right? Like, there's people delivering every 30 days. Now, we had this kind of, not nicely phrased category on demand, which we should just eliminate, because I don't know if that means every five minutes or every 18 months. So, I would kind of dismiss this, but the one way I would sort this away is like, if a third of the people think they can do on demand, that probably means they like doing on demand, so there's high aspirations to be able to deliver that way. So, there's this pull, this demand, so to speak, to deliver more frequently. There's a need for what DevOps delivers, right? It's not just sort of an obligatory thing, if you will. So, the next thing that we wanted to test out is what tools are in usage? What technologies are people using and how far along are they? So, again, we have these broad buckets of tools, right? And most of it's like not that interesting, if you will, right? Like, it's more or less penetrated with people thinking about it, right? It's not a done market, but you can see plenty of people have testing, lots of performance management, release management's doing pretty well, like all these things you would need with DevOps. And what's interesting and sort of confirming is this is sort of like the orchestration end-to-end service management category. And it sort of confirms, like when you go off into the DevOps or Radi land, like everyone's like, oh, we need orchestration. That's what we're lacking. We're gonna work on that next. And indeed, that's sort of what's missing that people aren't using very much. And if you peel back the covers here, what's also interesting about this is you ask the actual tools that people are using. So they may be satisfying the needs here, but you ask about the tools as we'll see. And they're actually using, let's call them pre-DevOps tools, right? So you see a lot of incumbent tools out there, not necessarily the utopic DevOps tool chain that you would expect. And to that end, one of the ideas of doing DevOps is that as this kind of oddly worded thing says, you achieve these efficiencies where you can deploy to production more frequently by using the same tools in each stage and development, QA, staging, and production. You try to use as many of the same tools as possible so you don't have this throwing over the wall and reformulating, right? So in the utopic DevOps world, you're essentially in development modeling how things are gonna look in production and using the same tools. So again, it's a bit hyperbolic and utopic, but we wanted to see are people actually doing that? And it turns out, they're sort of not, right? So I consolidated this down to automation tools, but it used to say automation tools like puppet, chef, salt, ansible, et cetera, right? So how much in this early DevOps, mainstream DevOps market are you using, are you doing this core practice of DevOps, of modeling your stuff in development with the same tools you used to do in production? And not that many of them are using these ideal tools. Now, they are doing like custom build scripts and golden images and all this stuff. And like, you know, this is always troubling. Like, you know, no one likes build people, right? The build team's always like annoying and like, they're not great. Like they don't believe in the moon landing and all sorts of things like that. So like, and the way that they maintain their control is with this, this custom written build stuff and it's just infuriating, right? And so like, you gotta get rid of that. That's just not responsible. And you know, I think it'll be interesting like golden image was sort of reviled by this little crew up here for a long time. And then all of a sudden Docker comes along and I realize it's not virtualization. I'm not supposed to say that, but it's sort of like the same thing. So we'll see how that pans out. So, you know, what's an interesting takeaway from here is that there's a lot of immaturity. Either the assumption is wrong about this being a core practice of DevOps or there's a lot of immaturity in the mainstream DevOps market about using this which means it's early in the market and there's lots of room for improvement which is a positive way of looking at essentially saying like DevOps isn't that pervasive in this one practice way in the mainstream market. So also in the technology area, you know, another thing that you know, you always hear in a DevOps context is you should be doing continuous builds and continuous integration and continuous X if you will. So we wanted to know like what CI tools are you using, if any, and things are slightly better here, right? Like, so this is like CI products like Jenkins and Hudson and Bamboo and so forth and so on, right? And, but what is kind of shocking is not only like, you know, there's a bit of a pass for doing your own continuous integration. I mean, again, it's really like, why are you spending your time doing that when you could not and just get it off the shelf or off the web thing to do it? So there's a large chunk that isn't using a standard way of doing CI, but then there's these guys, like what are they doing? Like, let's account for margin of error and say like 30 to 35% of the people have no continuous anything, like they're just doing continuous fail essentially up here. Like, so like that's kind of shocking. And again, it gets to the immaturity of the mainstream DevOps market and all the potential to like start doing something, right? So it's almost as if like, it's not even the glass is half full, the glass is like almost empty when it comes to the full potential of this. So then wrapping up here, as I said, hell is other people, right? Like this is my new core thesis and outlook on life in general. But you guys are lovely, I enjoy talking with you. So we also ask in this survey, like what's holding you back from like filling that glass, if you will, right? Like, why are you not achieving your potential, you sad sacks of people? And these are canned responses we had so we kind of limited them, but it's interesting to file these, to categorize them and file them away in your head, right? So most of them, I would say the majority of them, I forget what the number is, I think I put it in my notes here to be handily referred to, but around 70% of it is basically people-based problems, right? So most of the things that are holding people back are caused by people. And in fact, when we look at our other surveys that ask about why are you not advancing in cloud more frequent, like faster, it's also non-IT issues, right? It's resistance to change, budgeting, like people don't wanna do new stuff, it's people, right? So here, you've got the old, this is like what DevOps is supposed to solve, right? The old wall of confusion, an inefficient process of handing off between development and test and security and all these guys. So that's still like a huge problem out there. And again, in this very selective selection of people who are supposed to be DevOps folks, if you will, in the mainstream. So it's still a problem for them. And then there's like, my people suck, like the human resource constraints, which that's probably always persist, like you always want people to be smarter. But it is interesting that like skills are a real problem in this area, right? Finding people who know how to deal with the technologies and just like do, you know, act the way that you want essentially. And then there's always like, you know, this is also sort of like technical debt or infrastructure debt. Like it's a good like, you know, the gods of IT sort of like do that free will trick on you where they're like, well, you can commit infrastructure debt, good luck with that, right? Like I'm not gonna prevent you from doing it. And definitely like, there's all this complexity that you inherit by making shortcuts and changes and things. So that's definitely something holding people back. And then of course, there's the freaking product managers, right? Who are always like giving you new requirements midstream, right? Another thing that Agile and DevOps is supposed to address. But again, the summary is that when my sort of like fellow DevOps fans come up to me and like, hey, you gotta stop talking about tools. It's all about people. It's culture. Essentially, they're right, right? Like much of what you need to address are people and culture and process and change. And then you can bring in the tools, if you will. So to review our next steps, as I said. So essentially, what you wanna do in this environment, like as we were saying, you've got infrastructure complexity and things that may not work out. So if you wanna do DevOps and use computers to make the world a better place or make more money, you can choose which way. Essentially, you wanna segment out what you have. Like look at all the stuff you have, the projects, the existing things and segment it out and be like, this cluster of things, it's kind of a new application. It's not an old application. I could start applying cloud and DevOps to that. I'll be relatively secure with it. It's something that's doable and I'm not gonna get, it's not a quagmire, I'm gonna get stuck in. And then business-wise, it's very important to think about, don't just sort of like, spend your efforts on DevOps and new things on stuff that's not really differentiating to your business. And by differentiating, I mean, something that allows you to get more money from your customers or prevent them from leaving. Something that makes you different than other options that they have. We go to all like Michael Porter on what differentiation means, but who has the time for that? So you wanna pick something that's strategically valuable that's gonna help your business. And then also, based on the study and the stuff we were going over, like the, as the middle bullet points, the point of this, as the middle bullet point says, is that the usage of DevOps and also cloud is very early, right? Like it's not a done game and you shouldn't really feel too bad if you're not doing it yet, right? But it really is a good time to start POC-ing and trying things out. And if you're not doing that, then you probably are a little too late. Like you don't wanna be sitting here like two years from now and like, hmm, cloud, I haven't tried that out yet, right? Like you wanna experiment with some things and get some experience below, you know, below your belt, under your belt. So, and to that end, like as with any engineering-led thing, it's nice to start with small things that you'll be successful at rather than picking a big thing that you're gonna fail at. Like that's not cool. So you definitely wanna try something that's like small instead of doing big problems and build up to larger problems, if you will. And like I said earlier, you need to know how good or bad you are so that when you start applying these things you can figure out if you've improved or not. Because it would be kind of absurd with that a year after doing DevOps, like if you didn't know if it was better or worse than when you didn't do DevOps. And then finally, you know, as I was saying, my evolving outlook on life, hell is other people. Like it's clear that like the, you know, DevOps in my mind is sort of a continuation of agile and agility and getting the operations people more involved in this idea of everyone coming together and working better together. That's a lot of what agile addresses. And as you expand DevOps and cloud and agility and the rest of the company, the thing to keep in mind is the reason you're doing it is one, to reduce costs and also to increase speed, increase the release speed that you're having. And if you do just one of those, like if all you do is reduce costs and you're just virtualization, right? Which is great, but it kind of like runs its course. And then you're like, now everything's virtualized, now what do I do? But if you can target both of those, if you can both increase release speed, which means you get more features out to your customers and target more growth and it's cheaper, like that's a great combination of something to do. So when you're dealing with other people who are resistant to these things, tell them that like those are the points. Like tell them that, you know, it's worth their time to consider this because it's gonna be both cheaper and also better for the business. And to that end, one of the main things that I try to plot on about is, I don't think that the business, I'm sure that's a phrase you guys all use, like really expects much from us. Like they probably think IT is a waste of time and they're frustrating and like they're just the one that pop up windows and make it so that I can't like watch YouTube at work. Like IT is not a source of happiness for the business, right? And so as you get better and you can do great things with IT, you need to go back and engage with the business and be like, hey, you should ask more from me, right? Like I can do something, right? Like don't just outsource it or fire me and then do some shadow IT stuff. Like I could help you. Like I've improved, I don't drink as much anymore, right? And like essentially you have to reengage with them and train them to like ask for interesting things for you instead of just like managing your desktop unless that's what you like. So finally, you know, I think the big takeaway of hell being other people is that it really is like if you want to be militaristic kind of a culture war, if you will, like you need to like go out there and combat the, you know, the non-moon landing, believing people who want to do the old way and definitely like talk with the business people and change process over and get people engaged and more of a conversation about process and culture. And as a bonus, I, you know, we had DevOps days Austin a little while ago and Andrew Schaefer gave like a great cultural talk, if you will. There's all sorts of talks about Samurais or Samurais and wooden swords and metal swords and all sorts of stuff like that. And then like you kind of look at it and it's like, well, what's going on here? But it's a good talk and overview of the cultural side of DevOps. So with that, you know, to leave you with something that's hopefully is slightly inspiring, right? Like I think it's pretty clear like looking to the stuff that there's strong business demand for software development and custom coding, if you will. And there's lots of opportunity to satisfy it, but we're very early in like taking advantage of the opportunity and tools. There's a lot of maturing that we have ahead of us, but you know, there's great opportunity out there if you want to be in IT. So good luck out there. And with that, thank you.