Tag: DORA

  • DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey

    DevOps Chat: Nigel Kersten, Puppet, 2017 DevOps Survey

    I had a chance to sit down recently with Nigel Kersten, chief technical strategist at Puppet. Besides the fancy title, Nigel is one of the smartest, nicest people you will meet. Always a pleasure catching up with him. We spent most of our time speaking about the Puppet 2017 DevOps survey, which is now open right here.

    We also spoke about some of the findings of the past five annual DevOps surveys and the DevOps space in general. Great, informative conversation. As usual, the streaming audio of the our chat is below, followed by a written transcript. But please remember to take the 2017 DevOps Survey. Enjoy!

    Alan Shimel: Hi, everyone, Alan Shimel, editor in chief, devopsy.kinsta.cloud here, for another DevOps Chat, and today’s DevOps Chat guest is none other than Nigel Kersten, chief technical strategist at Puppet. Nigel, welcome back.

    Kersten: Hey, Alan—thank you. It’s great to be back, and always good to talk to you.

    Shimel: Absolutely. Nigel, you know—well, first of all, it’s always great to have you on the show, and we’d love to have you on as often as we possibly can, but specifically today, I wanted to talk a little bit about—it’s that time of year again where Puppet will be launching their, the annual DevOps survey, and I wanted to spend a little time talking about it and cluing our audience in, into what’s in store for this year.

    Kersten: Absolutely. Always happy to talk about the survey. So I think, you know, this has been—we’ve been running this for quite a while now, this is now the sixth year. And I think one of the things that’s really fascinating about the survey is, we survey generally technical practitioners, but also managers as well. But, in the course of surveying all of these practices and technical behaviors and how teams communicate with each other, we end up coming to a bunch of really great conclusions around the actual business outcomes.

    And this is why I think it’s so important for people to be going out and filling out this survey, because I see customer visit after customer visit, every time I’m out there on the road, so many people come up to me and say, “We’ve been trying to change the way we work inside our company, and your surveys turned out to be a really useful tool for handing to our senior management, and saying, ‘This is the sort of outcomes we can expect if you let us work the way we actually want to work.’”

    Shimel: Yes. And you know what, Nigel, just a little bit of a frame of reference, I got the number while I was at Gene’s last DevOps Enterprise Summit in San Francisco, but I was speaking to Nicole, Dr. Nicole Forsgren. What was the total—you may not know—but the total amount of people who have taken this survey at this point over the past five years?

    Kersten: There are actually over 25,000 people, which I think is fantastic, and particularly even in the first few years, we’re definitely really focused on the sort of North American market. We’ve been seeing this growing more and more in Europe, in Asia, and we’re starting to see that, really, DevOps has become a global movement and is being recognized as such within the enterprise, not just sort of the, you know, webscale hacker groups.

    Shimel: Yeah. Well, that’s certainly for sure. And Nigel, this year, is Dr. Nicole—well, they’ve actually started a company now around DevOps statistics and research.

    Kersten: Yeah, so we’ve been working with Dr. Nicole Forsgren and Gene Kim, who many people know from the author of, “The Phoenix Project,” and ex-CTO of Tripwire, and the inimitable Jez Humble, who many people know from his Lean Enterprise and Continuous Delivery books. We’ve been working with them for about the last four or five years and, yeah, this year they’ve formed a new company called DORA—DevOps Research and Assessment—where they go in and help companies do benchmarking around their actual sort of DevOps practices.

    Shimel: Yep.

    Kersten: And so I think that combination of industry experience, great sets of contacts, and really, the statistical rigor that people like Nicole actually bring to this—

    Shimel: Exactly.

    Kersten: —make this to be much, much more than just a vendor survey. Because it’d be easy for us at Puppet to just survey the Puppet user base and come to a bunch of conclusions. But I think the really interesting fact is when we get to talk to people—more people than are just using Puppet, people across the whole industry, some people who are just coming to DevOps for the first time.

    Shimel: Sure.

    Kersten: So I’d really highly encourage anyone who’s listening, you know, go out and fill out the survey when we launch next week, and don’t just feel like, “I don’t really know very much about DevOps, I shouldn’t fill out the survey.” We’re really looking for input from people all across the spectrum.

    Shimel: Absolutely. And of course, Nigel, by the time people hear this, it will be next week, and we will include the URL in the show notes so that people can click right out of this article to the survey.

    Kersten: Excellent.

    Shimel: Nigel, I don’t know if you would know this, even, but is there sort of a shortened URL that people can look for, to go to?

    Kersten: Yeah, we’ll give you a shorter URL by the time we actually launch this podcast out.

    Shimel: Okay. Not a problem. We’ll put that in there. So Nigel, six years in, though, if you’re not moving forward, you’re dying, right? [Laughter] As they say. What’s different about the survey this year?

    Kersten: Yeah, so I think we’ve really shown, over the last few years, that there’s a couple of practices that have really been formalized when it comes to DevOps enterprise adoption. We’ve seen that things like version control being heavily used in operations teams and that infrastructure being shared with your development groups, we’ve seen the role of continuous delivery and lean product management practices. So we really feel that, over the last four or five years, we’ve really shown a bunch of this stuff, that it really isn’t changing very much.

    So we’ve switched focus a little bit this year. So one of the interesting things we’re really looking at are the role of infrastructure architecture patterns in DevOps environments. And I don’t just mean, you know, “Are you adopting containers, are you doing macroservices, service-oriented architecture?” But we’re really looking for information on, architecture-wise, in terms of the way your application is set up, is your team self-sufficient and autonomous? Can you make changes quickly on your own, without lots of dependencies across the organization, and can you experiment really quickly?

    Because I think we’ve seen from Agile and from all of the DevOps enterprise movements over the last few years that the ability to do small tests and iterate quickly on the results of those tests to set your larger direction is really critical to both advancing your service, but doing so quickly and more reliably. Because I think that’s been one of the really huge sort of new things for senior management who haven’t been so familiar with these practices to realize is, adopting DevOps practices doesn’t actually mean sacrificing quality for speed or vice versa. It actually means you’re producing better, high-quality software more quickly.

    Shimel: Absolutely. So, Nigel, as I think you mentioned, this week, or the time people are listening to this, the survey will be open. Just in terms of time frames, how long will it be open and when do you think people might start getting a look at some of the data in the report?

    Kersten: Yeah, so we should be launching later on in the year as far as the results go. We tend to leave it open for at least a few weeks. Some of that sort of depends upon, you know, making sure we get a sufficiently large statistical base to get the conclusions that we’re actually looking for. So, the faster people want to see the results, the faster we want to see them fill out the survey. So, basically, head off and go and do it now.

    Shimel: Right. [Laughter]

    Kersten: As soon as we get that critical mass of data, we’ll be launching the results. So you’ll see us talking about this at Velocity, at the DevOps Enterprise Summits and a bunch of the different events happening.

    Shimel: Oh, I’m sure, I’m sure—looking forward to it. And being written about on devopsy.kinsta.cloud, I might add. [Laughter]

    Kersten: Absolutely.

    Shimel: For sure. So, Nigel, if you were king for the day, you know—

    Kersten: Okay.

    Shimel: —what would you, you know, and you looked into your crystal ball, what would the headlines be from this year’s survey?

    Kersten: If I looked into the crystal ball, what I would really like to see is that we’ve drawn some really strong conclusions around the benefits of DevOps practices in the public sector and in nonprofit organizations, because that’s been a constant source of feedback for the last few years, that we’ve managed to draw really great conclusions for profit-oriented companies.

    But I think we’ve also seen, with the rise of the U.S. Digital Service in the U.S. and .gov.uk that’s been running for quite a long time in the UK and the Digital Transformation Office in Australia—we’re really starting to see some of these practices start to be applied to the public sector. And, honestly, that’s in all of our interests, for government infrastructure to work more efficiently and deliver better services that progress more rapidly to all of us.

    So that’s something I would really, really love to see, that we can draw those conclusions, which I’m feeling pretty optimistic about. But I think the big headline I would like to see, continuing that thread of, “How do we make sure that the survey and the results in the report that we’ve come out with are useful for practitioners selling upwards in their organization, as well as senior leaders trying to implement change?” is—give your teams more autonomy. Make sure that you’re designing your infrastructure in such a way that they can test on their own, that they can rapidly experiment on their own, and that you can actually progress things much, much faster than we’re you’re needing lots and lots of meetings just to create major changes.

    So the more we can actually absorb the lessons of service-oriented architecture, and not just create a mass of complicated services, but create clusters of services that teams can work on with a high degree of autonomy and flexibility. That’s really the headline I would love to see—teams that are able to experiment and are autonomous will produce better results for the business.

    Shimel: Absolutely. Nigel, let me ask—go off on a little bit of another tangent, here. You know, one of the things that I kinda, I find fascinating and I tend to come back to and I get as much of as I can is the Project Blueshift stuff that you guys do at Puppet. Gareth Rushgrove is deeply involved in it. And while, today, you know, there’s certainly a strong container focus on it, it really is about sort of future-proofing Puppet, right, and making sure that the folks at Puppet are aware of, you know, what’s the next big thing coming down.

    What can we look for in the survey that may give us a clue in terms of what is the next big thing and hence, you know, something for Blueshift to be aware of?

    Kersten: Yeah, so I think we’ve generally tried to stay a little bit away from stuff that’s too vendor-specific research for us. But I agree—so you’ve totally captured what Blueshift is about for Puppet. It’s very much about us making sure that, you know, Puppet’s a highly successful project, you know, and used by tens and tens of thousands of companies across the world.

    But we’re in a very fast-changing technology landscape right now and I think it’s really critical for us as a company to make sure that we’re not just resting on our laurels there. We’re seeing lots and lots of things change. It’s entirely possible that, in 10 years’ time, everyone will be on completely serverless infrastructure, so to speak. And, you know, you might have been able to hear my air quotes somewhat around serverless, because there’s always someone’s servers running that code somewhere.

    Shimel: Right. [Laughter]

    Kersten: That old saying that the cloud is just someone else’s server.

    Shimel: Uh huh.

    Kersten: And I think, really critical for us, we’ve seen that Puppet, the language, has been an incredibly portable model. We started off in the UNIX and Linux space, and it’s proven to be hugely successful in the Windows space for a lot of our enterprise customers, and people really like having that common language describing all of your infrastructure. And we see no reason why, just as you’ve seen the Puppet container build stuff that we’ve done, that we can use the Puppet language to describe and compose containers and maintain that audibility.

    We can also describe all sorts of infrastructure, no matter where things come from. So, for us, Blueshift is very much about keeping that eye on the sort of next level horizon over the next six to 24 months, and just seeing what’s emerging and making sure that Puppet stays agile and that we start baking in the features to Puppet the language and the platform that will enable us to all take advantage of those things.

    Shimel: Sure. And I—

    Kersten: I think it’s really exciting. I don’t think we’ve seen infrastructure technology change as fast as this, ever.

    Shimel: It’s crazy. And, you know, I don’t know if it’s the gadget boy in me or, you know, I’ve lived in tech for so long, but it’s that—it’s not even a Puppet thing to me, Nigel, it’s a thing. What is the next thing? I think it’s a little bit of how I got into DevOps, it’s a little bit of how I got into computers and technology to begin with. So I’m always interested and curious.

    Kersten: Totally.

    Shimel: And sometimes, you know, the nice thing about this survey is, it does cast such a wide net of responses that you—

    Kersten: Yeah. And I wanna make sure that people don’t feel too left out as well. Because, you know, I often talk to people who are in big enterprise environments, managing important legacy applications, and some of them are still struggling with getting relatively basic principles adopted—of just using version control, using infrastructure as code.

    Shimel: Mm-hmm.

    Kersten: And sometimes you talk to them and they get a little demoralized, going, “You know, everyone’s talking about all this cool technology out there, and we’re not actually getting to use it.” But I think the reality is, most enterprise environments, the software they’re running is delivering actual business value, and it’s important to keep making sure that’s as efficient as possible.

    We saw from the “DevOps Handbook” that Gene and Jez and all of those people are involved in that you can apply these principles to mainframes, you know? You can see people taking incredibly legacy technology, applying these modern ways of working to them, and getting really, really huge benefits.

    Shimel: Got it, got it. Nigel, we’re almost out of time, unfortunately. You know, we can talk all day, but people only listen, it’s the curse of the modern, you know, the 10-minute or the 10-second sound bite and the 12-minute podcast—but first of all, good luck with this here survey. You know, I encourage anyone listening to go, please click on the link and fill out the survey. Can’t wait to see what some of the results are this year.

    Continued good luck with Puppet, too, as you guys are really, you know, coming out of Puppet Conference and meeting with Sanjay and some of the exec team, I was very excited about the possibilities, and I’m sure you are more than me—

    Kersten: Absolutely.

    Shimel: —about, you know, what’s on the horizon here for Puppet, so good luck with that as well. And thanks for being our guest on DevOps Chat.

    Kersten: No problem, Alan. It’s always great to catch up with you.

    Shimel: Okay, my friend. Nigel Kersten, chief technical strategist at Puppet, thanks for appearing on this DevOps Chat, and thanks for telling us more about the upcoming devops survey, or sixth annual devops survey from Puppet.

    This is Alan Shimel for devopsy.kinsta.cloud. Have a great day.

    — Alan Shimel

  • Iterative Indicators: Measuring DevOps ROI

    Iterative Indicators: Measuring DevOps ROI

    It’s well-established that application of ROI measurements to IT investment remains an imperfect science, and the same goes for ongoing adoption of DevOps methodologies.

    The fuzzy math of vendor-driven ROI calculators aside, even the most respected industry watchers have long struggled to create concrete parameters for assessment of technology spending. This, in large part, has been related to the fact that the requirement for continued investment has outweighed the value of short-term metrics.

    At the same time, it’s hard to put a price on the influence that paradigms including mobility, virtualization and the cloud are having on today’s business world. The scope of the so-called Applications Economy is only truly beginning to be realized.

    For in-depth discussion of DevOps ROI, register today for the upcoming webcast “Maturity Metrics – Analyzing the 2016 State of DevOps Report” with noted industry expert Gene Kim.

    With DevOps, the challenge of ROI measurement evokes similar characteristics as with these other bellwether movements. The affect that leveraging DevOps to become more agile and respond adeptly to changing customer expectations will have, long-term, ultimately will be realized as much in organizational viability as in any immediate cost-savings or other factors.

    That said, the recently published 2016 State of DevOps Report, assembled by the researchers at DevOps Research and Assessment (DORA), goes further down the path toward creating meaningful ROI metrics than any other such previous effort.

    For starters, the 2016 report builds on previous year’s conclusions that so-called “high-performing organizations”—those already deeply engaged in DevOps practices—are “decisively outperforming their lower-performing peers in terms of throughput,” and this gap continues to widen.

    Moreover, DORA contends that high performers deploy applications code 200 times more frequently than slow performers and achieve 2,555 times faster lead times. Perhaps even more importantly, in particular as it relates to the ability to improve applications performance, the report estimates that leading DevOps practitioners lay claim to 24 times faster recovery times and three times lower change failure rates.

    The State of DevOps Survey, completed by roughly 4,600 technology practitioners, also found that high-performing teams spend far less time on so-called “unplanned work and rework”—most often required to address existing problems—allowing them to spend nearly 50 percent more of their time on new work. The latter brand of effort is typically aimed at adding or improving feature functionality—or, in simple terms, innovation.

    As increased software velocity and reduction of MTTR represent the most critical differentiators in today’s environment, where an end user may wait only seconds for an app to load before abandoning your brand altogether, these conclusions obviously carry impressive weight.

    Finally, based on a framework established by research analysts at IDC which suggests that hourly application downtime costs can range from $1.25 to $2.5 billion for a Fortune 1000 firm, and that the average cost of a critical application failure is $500,000 to $1 million per hour, the State of DevOps Report allows for the conclusion that high-performing organizations save an average of more than $91 million per year.

    Much of this advantage is found, the researchers note, in the form of lower applications change failure rates, or those updates to software code that result in subsequent performance issues or outages. While high-performing DevOps practitioners experience an average change failure rate of 7.5 percent, medium-performing organizations see that figure rise dramatically, to a whopping 38 percent.

    If the undeniable adage that “time is money” applies in today’s Applications Economy as much—if not more than ever—than these ROI calculations would appear to infer substantial meaning.

    Later this month, Gene Kim, one of DORA’s founders and a key contributor to the State of DevOps Report, will host a webcast with CA Technologies expert Aruna Ravichandran to discuss DevOps ROI and many other related topics. Register for that event today.

  • Puppet Labs Launches Annual State of DevOps Survey

    Puppet Labs Launches Annual State of DevOps Survey

    Puppet Labs has announced its 5th annual State of DevOps Survey. In the past five years, we’ve surveyed more than 20,000 technical professionals around the world, spanning all industries and companies of all sizes. We’ve captured a tremendous amount of data about how IT performance, culture, technical practices and organizational performance intersect.

    What sets our survey apart from the many other surveys out there is that it’s science-based. Yes, there is a science to creating surveys and analyzing data, and there’s also an art to translating all of that amazing data into something that’s useful to the industry at large.

    This year, we’ve partnered with DevOps Research and Assessment (DORA), founded by our friends Gene Kim, Jez Humble and Nicole Forsgren. If you’ve been following the DevOps conversation for a while, their names should be familiar. Together, our goal is to help advance the DevOps community and help technology organizations improve their practices through rigorous scientific research.

    Through our analysis, we’ve been able to quantify IT performance. We know that high-performing IT teams deploy code 30 times more frequently, with 60 times fewer failures, and they recover 168 times faster. We also know the factors that predict IT performance—technical practices such as continuous delivery, cultural norms and lean management—which in turn predict organizational performance.

    This year’s survey seeks to dive deeper into each of these areas, while also shedding light on new areas of research, including:

    • ROI of IT performance. What can you expect from your investment in DevOps? Our goal is to understand how throughput, stability and quality affect the bottom line.

    • Security and compliance. What role do security and compliance play in a DevOps environment? Some people see security as a roadblock to DevOps, but we want to investigate if it has to be that way.

    • Quality. So you’re deploying code faster than ever. What’s the quality of that code?

    • Containers. How do containers affect IT performance? Are they making IT’s job easier?

    • Lean management. Last year we found that lean management practices such as limiting work in process and creating and maintaining visual displays showing key quality and productivity metrics predict IT performance. This year’s survey looks at additional lean management practices to help us better understand what it really means for a technology organization to go lean.

    The survey seeks answers to questions we get all the time and we believe they reflect the broader concerns of the DevOps community. Your experience matters and we hope you’ll share it by taking the 2016 DevOps Survey. It should only take about 20 minutes, and when you complete the survey, you’ll be entered to win some great prizes (see the official rules), including :

    Please take the survey and share it with your friends and peers. Together, we can make IT better for everyone.

    About the Author/Alanna Brown

    unnamedAlanna Brown heads up DevOps research and go-to-marketing strategies at Puppet Labs. She also works closely with Puppet Labs product owners and engineers to develop a roadmap and support for Puppet on Windows.