devopsy.kinsta.cloud

Author: Alan Shimel

  • DevOps Chat: Design Thinking w/ Sarah Plantenberg, IBM

    DevOps Chat: Design Thinking w/ Sarah Plantenberg, IBM

    We sit down with Sarah Plantenberg of IBM to talk design thinking. Sarah has been featured on several DevOpsTV videos around the Bluemix Garage. But she recently took on a new role at IBM around bringing design thinking to cloud customers. Sarah gives some great background on design thinking and why it can help you. Have a listen for yourself and we think you will find it informative.

    As usual, the streaming audio of our conversation is below with a transcript of our conversation below that. Enjoy!

    Alan Shimel: Hey, everyone. This is Alan Shimel, editor in chief, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Our guest on this episode of DevOps Chat is Sarah Plantenberg of IBM. Sarah, welcome to DevOps Chat.

    Sarah Plantenberg: Thank you. It’s great to be with you again.

    Shimel: Great to have you on again, Sarah. As we spent, oh, a good half-hour chatting before we went on air today, just catching up, and it’s always great to hear what’s going on in your world, and, obviously, one of the big things is you now have a new title at IBM. I’m not even gonna attempt to repeat it because I know I’d mess it up. I’ll leave it to you to tell our audience what exactly is your new title, Sarah?

    Plantenberg: My new title is I’m a design lead, the designer for the offering management section of our cloud technical engagement organization, so I’m a senior consultant specializing in applying design thinking to our business and helping our clients apply design thinking to their businesses.

    Shimel: Absolutely. And, though that may not roll off the tongue, it’s actually a mouthful, in terms of how important and how much value IBM puts on this whole concept of design thinking. But, Sarah, some people in our audience may not be familiar with design thinking. Design thinking 101 for people who don’t know what it is, how would you describe it to them?

    Plantenberg: Design thinking is about understanding and then innovating in a really human-centered way. We understand the person that we’re building something for. We understand their current situation. We understand the greatest pain points they have or if you’re bringing something new to the market, what’s the greatest opportunity for your business. And then we innovate around that by really—we have some really great techniques and tools to help people come to ideas that they would not have come to if they were just sitting down, doing what they call a typical “brainstorming session.”

    Shimel: Mm-hmm.

    Plantenberg: Once you have those ideas, you have to take those and put them back in a context of that human being’s world. How many great ideas have we all come across? The example I give is that I have 150 applications on my phone and I use, honestly, probably 15 of them.

    Shimel: Yeah.

    Plantenberg: There’s a bunch of great ideas. [Laughs] But they don’t reach me in the right way at the right time. So design thinking is really a set of—a framework and a set of tools around helping bring all of those things together, and, in IBM, we use it to bring the right technology to the right person, at the right time.

    Shimel: Excellent. And, of course, Sarah, design thinking, while IBM is probably one of the leading advocates in the world for the concept of design thinking, it’s not—this is not a new concept, per se. design thinking has been around for a while. Again, design thinking 101 for our audience—give me a little, if you can, a little of the history that you know of there

    Plantenberg: So, yes, design thinking’s been around for many years. What IBM has done with design thinking is said, “You know, we really need to apply this … ” We’ve done three things. The first one is to say, “We really need to apply this to the way that we work . We need to understand how we’re positioning ourself, how our clients understand us, what they need, and really target IBM’s capabilities towards those.” And, in some cases, even a couple steps ahead of the game, what we see coming in the market, which is really where the cognitive capabilities and the way that Ginni Rometty is steering our company—that’s where that comes from, is understanding that’s really the heart of design thinking.

    The second thing that IBM has done with design thinking is help us use it at scale and teach our enterprises to use it at scale. It’s easy to do design thinking in the small, but to do it when you have a development team of 250 or when you have a development team that’s in India, China and New York? That’s a different ballgame. So IBM design thinking, IBM’s part of that is at speed and at scale.

    And then the third thing that we’ve done with it is what we’ve done in Garage, which is really to take an incredibly lean and integrated approach—you don’t have to integrate design thinking into your development, but we do. And we do that in the Garage and it’s been amazing because it’s helped people use design thinking and kind of allow it to permeate everything that they do, so we put it at the beginning to understand the users and come up with innovative ideas and then design those and develop them for users towards business outcomes, but we also use it to say, “Okay, now you’ve adopted that cloud, Client A.” Let’s pretend. You know, just talk about a client without using their name. “You’ve adopted the cloud; you’ve brought in the IBM Bluemix Garage Method. You’re iterating really quickly. Your agility now means something to the user.” Before that, without including the user, agility more often has strong IT economic benefit, but it doesn’t always follow the business, and so design thinking really connects those two things together.

    And then, once you adopt the cloud, it ripples. The impact of that ripples, so you can’t run your operations organization in exactly the same way that you did before because you have different tools and you’re running at different speeds or maybe you’re running at just one speed that’s a lot faster, and you have somebody else managing your cloud, so what does it mean to do DevOps? So we created a design—we applied design thinking to how people reorganize their operations organization, and that’s been a great tool for us, both to learn, as IMBers, about how our clients need to shift and also to help our clients really take an outside-in approach, a human-centered approach, to how they’re gonna run an operations organization.

    And I think the last thing I would say about that is you can also use design thinking at the business process level as well, so it’s—I could go on and on with this answer [laughs], but I would say it’s—

    Shimel: Oh, it’s okay.

    Plantenberg: —it’s really stepping back and looking at the big picture and understanding, rather than following the thread. You know, it’s taking a holistic approach, rather than a linear one, to operations.

    Shimel: Yep. And, you know, Sarah, one of the things about the Garage and the Garage Method is really kind of taking this design thinking kind of way, if you will, and applying it, in real world, to scaling at enterprise levels and in a agile fashion, right? And by “agile,” we don’t necessarily mean Agile manifesto, Scrum, but agile in a larger sense. And, Sarah, that’s actually something that you and I spoke about off-mic earlier, and that is what I call, or Gartner actually calls, this concept of “agile IT,” but it’s also something, as you pointed out, that has been preached from the highest levels at IBM now for at least the last couple years, which is kind of agile everywhere or, you know, going agile, if you will. Why don’t you, if you can, share with our audience a little bit about what that means to you and what is IBM’s kinda vision on that?

    Plantenberg: You know, what that means to me, I can’t separate my life at IBM from my life as a designer, when I answer that question, ’cause I’m a designer because I think like one—I didn’t choose to be one; it kinda chose me.

    Shimel: Yeah.

    Plantenberg: And, from that standpoint, I think that the only reason to be agile is to be responsive. There’s no other reason you would need to be able to shift quickly, unless you’re in response to something. In my world, that’s a user, and a user can be my manager; the user can be my team, when I was managing a design team; they’re my client. They’re the people I interface with because I’m doing something for them. Whenever I’m doing something for someone that’s my user, I need to be agile. But, as we talked before, where agile meets non-agile, you end up with kind of a mess. It’s a little bit of a—there’s cognitive dissonance. People can’t work together because they’re working in two different ways—it’s a square peg in a round hole.

    And so the concept of agile in the large, “Let’s all operate in the same way and let’s all have that way be inclusive,” meaning we integrate together, we know how to pass information together. We are all aligned around the same priority, so, when you ask me for something and I say I can’t get it done because X, Y, Z, say, “Yeah, I understand that, actually. Let me make sure—let me put this in the right priority.” And are all responsive to changing business needs—I think that’s the most important thing. When the tides shift, we all see it together because we’re aligned together. We can then respond together. And it’s an incredible way of working.

    Jeff Smith had brought this into the CIO’s office, and it’s been incredible, the results. I wish I had them in front of me. The reduction in the amount of time spent getting things done, streamlining the organization, and I literally mean streamline the organization. It got smaller. It’s tighter. It’s faster. It’s more responsive. We’re now rolling that out under Sean Reilley who’s the vice president. Moved over to GBS, our global business services, and that’s now an offering for our clients.

    And it’s very, very interesting to our enterprise clients who are having to do more with less—I hate that phrase, but it’s true [chuckles]—and they’re having to be more responsive because business is changing so fast, the conversations people have now about the cloud are vastly different than they were only two years ago, so enterprises can’t be responsive not only to emerging technologies but to what their users need and how the markets are shifting. They’re struggling, you know? And so this is really a fantastic answer ’cause it’s not a thing that you buy; it’s a way of being and a way of thinking and a belief system.

    And I think the last thing I’ll say about it is it really allows the people on the ground to use their capabilities to help change the business. Instead of being told what to do, they’re leading with what they know, within a framework that gives them a voice and gives them a method of working together. It’s just—it’s fantastic work.

    Shimel: Excellent. Excellent. So, Sarah, as you mentioned at the top of the podcast, you recently moved into a new role, where, before, you kind of really weren’t in the Garage and around design thinking with the Garage and Garage Method. You’re now helping IBM’s sales, marketing team, customer engagement teams both understand design thinking internally there, as well as taking those lessons and bringing it to market, to IBM’s clients. Is that correct, fair to say?

    Plantenberg: Yes, it is.

    Shimel: And, in that role, Sarah—and I’m sure you’re very excited; it sounds like an exciting new role and we all like to embark on new opportunity—what does success look like for you there?

    Plantenberg: Oh, what a great question [laughs]. Success … I often success for myself as having created something that doesn’t need me ’cause if it needs me, than it’s more about me than it is about an outcome, so I will say that that’s the preface ’cause my answer might, without that, sound a little weird. Success to me is that I can stand back and watch our clients move from the beginning of their cloud journey to the point at which they have a hybrid cloud and they’re running in the cloud method and getting tremendous value out of it and hopefully even having spread agile methods throughout their business and adopt design thinking and that human-centered approach, and they’re doing beautifully with IBM’s tools integrated with anything else that they may have. I want it to be easy for our clients to find what they need on the cloud – about the cloud, on the cloud methods, tools, understanding the capabilities on Bluemix and growing their businesses with those and being independent and thriving on Bluemix.

    Shimel: Great. That is great. And so, I mean, the Bluemix and all of that is still there. One—I think we have time for maybe one more question we can go into, Sarah, and that is I wanted to talk to you about the concept of multi-clouds, right? We become more nuanced in our understanding of what it means to move to the cloud. We’re not all moving all of our infrastructure up to Amazon or Azure or one of these public infrastructures, the service providers. Cloud exists in many forms, right? We have public cloud; we have private cloud; we have hybrid cloud; we have lots of flavors, almost as many flavors of computer clouds as there are different types of clouds in the sky. What does this mean to you and in terms of your role?

    Plantenberg: It means understanding the people who are having to make the decisions. I think that your analogy of clouds in the sky is really—it’s a great one because you don’t—we can’t expect people to only want cirrus clouds, and here comes a cumulonimbus cloud. “No, I’m sorry. I can’t have that. It’s not gonna work for me; I only do cirrus.” That’s not how the world is. We have to be comfortable and understand people are making different decisions and connecting these different clouds togethers, and, often, I actually meet clients who have one area of their business using one cloud and then another area, using another cloud because the business folks had a small, little consultant group who’s working on Amazon and the IT organization decided to go with Bluemix, and now they have to figure out how to integrate these two.

    That’s the world we live in, and people make choices for reasons. If we understand, from a design standpoint, “Why do you have these multiple clouds? How are they working together? Where do you wanna take your business?” then we know how to fit these things together and knit them together and do automations. In fact, we have some automating tools that say, “Okay, we can run a dashboard that helps you see all of your clouds,” so IBM no longer believes in backing up the IBM truck and saying, “Us or the highway.” That doesn’t work; it’s not the kind of world we live in. And everything is integrated—it’s really the name of the game—and so, for me, it’s understanding how people got to where they are and understanding where they wanna go and being able to bring them there with what they have.

    Shimel: Got it. Got it. Well, Sarah, we’re about out of time, so we need to end things in a little bit, but I wanted to, first of all, thank you for appearing on this episode of DevOps Chat and, secondly, really wish you nothing but the best of luck with this new role and responsibilities. We’ll be checking in to see how things are. And then, of course, we’ll see you next year, hopefully, at IBM InterConnect, and that’ll give us maybe six months or eight months of retrospective to take a look at and we can see what it’s about.

    Plantenberg: Oh, I count on seeing you there, Alan. [Chuckles]

    Shimel: Okay. That’s—I guess we’ll call it a wrap on this episode of DevOps Chat. Sarah Plantenberg, IBM, design thinking. Thank you so much for being our guest on this episode of DevOps Chat. This is Alan Shimel for DevOps Chat and devopsy.kinsta.cloud, and we hope to see you soon on another DevOps Chat.

    — Alan Shimel

  • Q&A: Michael Beckley, CTO/CCO, Appian

    Q&A: Michael Beckley, CTO/CCO, Appian

    Recently I had the chance to speak with Michael Beckley, chief technical officer and chief customer officer at Appian, about his company’s move to go public and the DevOps space in general. For those of you who don’t know Michael, he is a founder of Appian and leads the company’s technology vision and oversees customer initiatives worldwide. He also serves on the Industrial Advisory Board for the University of Virginia’s Computer Science Department and is a member of the University of Maryland Advisory Board in Computing. He has an interesting take on the IT space and DevOps in particular. Read on for our discussion.

    Alan Shimel: Michael, what do you think has been the “special sauce” that has led to Appian’s success to date?

    Michael Beckley: With Appian, companies build unique business applications up to 20x faster and mobile-enable and modernize existing systems. For example, a company like Ryder was able to build a web and native Android tablet application that cut the time it took to rent a truck in half.

    But the “special sauce”? That’s Appian’s culture of innovation. Our engineers think long-term and invest in breakthrough tech like our patented SAIL UI technology for zero code native mobile apps. Thanks to SAIL, the web apps you configure in Appian automatically deploy to iOS and Android as native, full-featured apps or specialized micro apps we call “Sites.” As long as we get the culture right, we expect to continue to deliver enduring value for our clients.

    Shimel: With becoming a publicly traded entity, some companies have found “managing to the street” does not match their own long-term business plans and their customers needs, how does Appian avoid this?

    Beckley: Companies, like people, are an aggregation of their habits. Appian’s habit has always been to hold to our long-term vision of enabling every company to be a software company. We are not your typical Silicon Valley tech company. Our roots are in DC, we largely bootstrapped this business, and learned to be good stewards of capital while helping to support the core missions of federal agencies and some of the world’s largest brands. The proceeds following this IPO will be invested back into our business to benefit our customers.

    Shimel: What do you see post-IPO being the biggest areas for growth as it relates to new products and services?

    Beckley: We  plan to invest in innovating and enhancing our platform. While our platform is industry-agnostic, we have recently made, and plan to continue to make, investments to enhance the expertise of our sales and marketing organization within our key industry verticals of financial services, health care and government. We have made, and will continue to make, investments in research and development to strengthen our platform and expand the number of features available to our customers. As we continue to increase the functionality of our platform and further reduce the amount of developer skill that is required to build robust applications on our platform, we believe that we have the potential to expand the use of our platform.

    Shimel: Digital transformation is a term that is being used a lot these days. How far along the adoption curve are we on digital transformation?

    Beckley: While many speculate that digital transformation is just a tech industry buzz word, in reality, digital transformation is a living, breathing effort. According to a recent survey, digital transformation is a C-level priority and is considered a top focus for almost 50 percent of all companies this year.  From Appian’s perspective, we believe that the utilization of low-code software to drive digital transformation is still relatively new and our customers will be able to succeed in their digital transformation efforts by incorporating low-code development.

    Shimel: Where does the DevOps market intersect with the Appian business model?

    Beckley: Organizations are turning to DevOps to accelerate development and bring an application’s capabilities to a user quicker. The Appian low-code development platform fits into the DevOps model and supports the seven major DevOps categories including code, build, test, package, release, configure and monitor.

    Overall, our business model supports the DevOps market; we’re living in a world where citizen developers are playing such an important role in the enterprise and our platform empowers the citizen developer while alleviating developer resources to focus on the more challenging, business-critical developer work.

     Shimel: What about containerization and microservices? How do these technologies affect Appian?

    Beckley: Appian already uses containers and microservices. Appian’s enterprise customers often require a mix of cloud, hybrid cloud, and on-premise installations. We view containers and microservices as enabling technologies to support the diverse workloads and deployment models required by our enterprise clients.

    Shimel: What about security? What challenges does cybersec pose to Appian’s development of their platform?

    Beckley: Appian works with some of the nation’s most important and highly regulated industries, therefore we have built a comprehensive security and compliance structure that meets several industry standards. We frequently undergo third-party audits to ensure that we are always operating effectively to protect our customer data.

    — Alan Shimel

  • DevOps Chat: Waterfall Will Not Disappear, with Flint Brenton, CEO Collabnet

    DevOps Chat: Waterfall Will Not Disappear, with Flint Brenton, CEO Collabnet

    One of the perks of being editor in chief of devopsy.kinsta.cloud is I get a chance to meet with so many leaders of the DevOps and IT industry. You can really learn a lot by listening to what these folks say. This DevOps Chat is a perfect example. I sat down with Flint Brenton, CEO of Collabnet. Collabnet is not some johnny-come-lately. The company has been helping developers and IT professionals for a long time. Flint talks about the fact that while DevOps is a great path for many organizations, it may not be the right way for every situation. Waterfall is not going away entirely.

    Have a listen to my discussion with Flint and hear for yourself what he has to say on the subject. As usual, the streaming audio player is immediately below with the transcript below that. Enjoy!

    Streaming Audio

    Transcript of Audio

    Alan Shimel: Hey, everyone. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Happy to be joined in this DevOps Chat by Flint Brenton, CEO of CollabNet. Flint, welcome.

    Flint Brenton: Hey, Alan. It’s great to see you again.

    Shimel: Great to see and hear you again. Flint, the last time I think you and I talked was back at the DevOps Enterprise Summit in San Francisco. I guess that had to be October or November.

    Brenton: November. Actually, it was the same week that our new president was elected, if you remember.

    Shimel: Yes. Yeah, a red letter day.

    Brenton: Right.

    Shimel: So, Flint, without getting any further into that, let’s turn the conversation to CollabNet. What—well, first of all, maybe some of our audience is not familiar with CollabNet in general, so why don’t we start with that? Can you give us a little CollabNet background?

    Brenton: Yes, absolutely. So CollabNet is a SAS-based, cloud-enabled development platform focused exclusively on enterprise that delivers application lifecycle management capability for both Agile and waterfall development processes.

    Shimel: Mm-hmm.

    Brenton: The version technology to structure those builds and to maintain high quality and high quality control throughout the process. And then we also provide the DevOps infrastructure to build and deploy automatically whatever gets created in Azure or waterfall, with high quality, on time, and, to the extent we can help, under budget. So that’s really our focus.

    Shimel: Sure. And you know what, Flint? I remember this about CollabNet. You guys have been in business now for a number of years, certainly before DevOps was what it is today, let’s call it, whatever it is today. How long have you been—

    Brenton: Yeah, we’ve been in business—this is our 18th year.

    Shimel: Absolutely. So, you know, DevOps is another technology innovation, if you will, that’s come down the road, but I think what—not unique, but what is one of the special qualities of CollabNet is is that you’re not out here saying that the whole world needs to go DevOps today, right, that everything—we should be all DevOps all the time. But you have customers who are still on waterfall and may very well remain on waterfall for the foreseeable future.

    Brenton: Right. And we really invest very heavily in both waterfall and Agile development platforms and—although the growth rate for Agile’s higher than waterfall in enterprise, we still see roughly 70 [percent] to 75 percent of enterprises using a waterfall methodology. But the fastest growing segment in that area is clearly Agile.

    Shimel: Sure. And I—obviously. But I think what’s important for our audience to recognize is even the biggest DevOps and Agile advocates or biggest—whatever you wanna call ’em, should recognize that there are still projects and places where waterfall might be the best way to skin the cat, to complete a project correctly. And it doesn’t have to be an all-or-nothing type of environment, if you will.

    Brenton: That’s exactly right. You know, the industries that tend to be highly regulated, with a high need for security, compliance, and scalability, tend to lean more towards waterfall development. And, of course, once you started a process where you’ve got an established team that’s been using waterfall for a long period of time, they tend to prefer to continue with that. But it’s new projects, new projects where maybe time to market outweighs the need for compliance and security and scale—those tend to go Agile in an enterprise. But, either way, regardless of development methodology, the things you need beyond the tool chain or the process of building software is fairly similar, right? The way you use version control is fairly similar. The way you use DevOps technologies is also very similar.

    And what we found is customers who are well grounded in Agile and waterfall—typically, in enterprise, they have both—getting your act together in DevOps and making sure you have a strategy, you created a culture to embrace and execute that strategy, then having the processes and tools in place to bring it to reality is critical because you don’t really get the return on investment for anything you develop, regardless of the methodology, until you put the build into production. And that’s what DevOps, at the end of the day, is all about.

    Shimel: Sure is. Excellent. Excellent point, Flint. Flint, let me turn things a little bit ’cause, as I mentioned to you off camera, off mic, 15 minutes here goes pretty quick. Want to talk about some recent news around CollabNet in the industry. I understand you guys were just included in a Gartner Magic Quadrant, correct?

    Brenton: Yes. Yes, thank you for bringing that up. Yeah, we’re very excited about it. It’s always a reflection of the investment our team has made in Agile planning and execution. So we’ve always been considered a leader when it comes to waterfall development, but, as we just mentioned, for enterprise, our enterprise customers are really demanding that we provide both, both equal value in waterfall and Agile. So we invested heavily in the last few years in Agile, and, as a result, we were just included in their Magic Quadrant as a visionary for Agile planning and execution, and we’re very excited about it.

    Shimel: That’s nice. That is great. And I know everyone always wants to be in the upper right, but, really, having my background, being entrepreneurial and having started businesses, I’d almost rather be in that visionary quadrant than the upper-right leader quadrant and certainly in the visionary quadrant over, let’s say, the challenger quadrant, which is the upper left, because I think, with visionary, I mean, the recognition is that you’re setting a—you’re pushing the envelope, right? You’re pushing the vision—hence, “visionary.”

    Brenton: Right.

    Shimel: So congratulations to you guys. I know, in speaking with your team, you have rights for download of the quadrant, so what we’ll try to do is put into the show notes here a link to that where people can download the quadrant report and see if—check it out for themselves.

    Brenton: Yeah, that’d be perfect and I’m sure that your listeners would very much appreciate that.

    Shimel: Sure will. So, Flint, beyond the quadrant inclusion, though, what else do you see that’s happening with CollabNet or in the market in general?

    Brenton: We’re starting now to get a number of customer wins that are embracing our motto of providing a cloud-based service where you can consume our integrated ALM, version control, and DevOps solution either in Amazon or on our own private cloud and, in many cases, a combination of on-prem and off-prem.

    Shimel: Right.

    Brenton: So we now have a number of customers who have completely moved their development process into one of our cloud-enabled environments, and it’s very exciting.

    Shimel: That is exciting.

    Brenton: It’s very exciting. And the great (thing) about that is, if it’s in the cloud, it’s actually easier for us to include, Alan, both open-source and compare it to components that we don’t own or control because then the need to test to get everything in your data center  is lessened and our ability to innovate to your advantage is much greater, so we’re very excited about that.

    Shimel: Absolutely. So, Flint, interestingly enough, I was reading an article this morning—I forgot where I saw it but it was a recent survey where 65 percent of enterprises still keeping the majority of their infrastructure on their own data center, not on a public cloud, not a hybrid situation. Is that about what you guys are seeing but is the arrow pointing up to the cloud? What’s your take on that?

    Brenton: Now that’s a great question, Alan, and it’s absolutely what we’re seeing. So a thing to keep in mind, though, is “What is the variable that’s changing and what is the velocity of that change?” Right? So I would say, two years ago, that 65 percent number was probably 90-plus, right? So, as enterprises get more and more comfortable with the security and compliance options in the cloud, whether it’s in a public cloud or private cloud, they can see the tremendous advantages of driving down the cost of development and actually increasing the speed of innovation by going to the cloud.

    I’ll give you an example. U.S. government, we do a tremendous amount in federal, and so both the Obama administration and now it’s transitioned to the Trump administration has really been pushing the department of defense to do a couple things. One, innovate faster, and so, if you just think about the U.S. government is barraged by cyberattacks from all over the world. Right?

    Shimel: Mm-hmm.

    Brenton: And so your ability as a professional, in NSA or CIA or the FBI, to deal with that is you want a complete toolkit of things you can use, and you want to choose the tools you need to deal with those cyberattacks, but you also need to do it quickly. So if you can use open source, it helps. If you can deploy it in a cloud, it dramatically increase—or decreases the time to deployment. And, three, it also tremendously helps you on the economics side. So even something as highly regulated and structured as the US federal government, there are advantages sometimes in doing things in a public cloud to help, and so we’re starting to see variations of that theme also in industry, primarily around enterprise, where there’s flexibility, increased ability to innovate, and improved economics by moving workflow to the cloud.

    Shimel: Yep. You know, Flint, living in the tech world and you lived the world—you live that life; I live that life—I think sometimes we get  jaded in that we’re in this bubble of, “What’s the hot new thing?” and it’s DevOps and it’s whatever’s next after DevOps, and then sometimes you get a reminder—65 percent still not in the cloud. And you say, “But I thought everyone’s in the cloud.” And I think it does good for us to remember that there’s a big world out there that moves at their own pace and their own—

    Brenton: Right.

    Shimel: Same thing with waterfall. Right? I think people would be—people in our audience from devopsy.kinsta.cloud would probably be surprised to find out how many organizations still either haven’t adopted DevOps or are primarily waterfall shops.

    Brenton: You know, the key, when you’re a solution provider like CollabNet, is you need to meet people where they are. Right? So, if they wanna be on-prem, you need to be able to deliver them superior value on-prem. If they want to move part of their workload to the cloud, you need to be able to help lead them and sponsor that transition at that pace by which they’re comfortable. Right? So I learned a long time ago the key to success in this business is to give people what they want, right? He who can do that best with a quality solution at a great price is gonna win. Right? So that’s just the way it works, right?

    Shimel: Absolutely—and that hasn’t changed, by the way, through all of these innovations, and I think it was true 100 years ago and it’s true today. Or maybe even more than 100.

    Brenton: You bet.

    Shimel: Anyway, Flint, listen, I think we’re about out of time here. I wanna be respectful of your time, so what we will do is let’s have you on again soon when we have some more time and we can delve into this. Are you gonna be at DevOps Enterprise Summit maybe in London?

    Brenton: You bet. Yeah.

    Shimel: Or San Francisco?

    Brenton: Well, I always enjoy speaking with you, Alan. You’re a great guy and you’re—

    Shimel: Thanks.

    Brenton: —you’re a fun guy off camera too, I will add.

    Shimel: [Laughs]

    Brenton: So I look forward to our next adventure together. Thank you for the—

    Shimel: Absolutely. Hey, Flint—

    Brenton: All right.

    Shimel: Flint Brenton, CEO of CollabNet, this week’s guest on DevOps Chat, thanks for joining us. This is Alan—

    Brenton: My pleasure, Alan. Thank you.

    Shimel: Thank you.

    Brenton: All right. Buh-bye.

    Shimel: This is Alan Shimel for DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Value Stream Mapping with CollabNet’s Eric Robertson

    DevOps Chat: Value Stream Mapping with CollabNet’s Eric Robertson

    This DevOps Chat features Eric Robertson, VP of product and engineering at CollabNet. We discuss value stream mapping, which comes from Lean methodology and has been around for a while. But do you actually know what value stream mapping is? How can it help your DevOps transformation? Eric does a good job of explaining.

    As usual, the streaming audio of our conversation is immediately below, followed by a transcript of our chat. Enjoy!

     Streaming Audio

    Transcript of our Chat

    Alan Shimel: Hey, everyone. This is Alan Shimel of devopsy.kinsta.cloud here for another DevOps Chat and our guest on this chat is Eric Robertson, VP of product management and engineering at CollabNet. Eric, welcome to DevOps Chat.

    Eric Robertson: Thank you. Thank you, Alan. Glad to be here.

    Shimel: Yeah. We’re glad to have you here, Eric. I don’t think we’ve had anyone from CollabNet, actually, on DevOps Chat before, though I think we’ve done some video interviews over at DevOps Enterprise Summit—maybe it was San Francisco in October and November—but we’re—so we’re glad to have you here. We’re eager to find out about what’s going on with CollabNet and about some of the stuff you’ve been doing. Eric, if you don’t mind, though, there might be some people out in our audience who are not familiar with CollabNet, so, if you can, just—doesn’t have to be long, but maybe a quick elevator pitch on who CollabNet is, what you guys do.

    Robertson: Sure. Sure. So CollabNet’s been around since, I think, 1999, and it was one of the foundational on the open source, with our Subversion version control software. We since then moved into the ALM, application lifecycle management, platform. It’s our product offering called “TeamForge,” where we started linking in that planning, development, and testing life cycle, with integration to tools. And now, with me, we actually extended that life cycle all the way down into the operations—thus, the concept DevOps. And now we are launching—have launched, actually, a series of products and partnerships around DevOps for our customers.

    Shimel: Fantastic. Fantastic. So, Eric, one of the things that, when we spoke off mic earlier, we spoke about value stream mapping, and I know that’s something kinda, if not near and dear to your heart, something that you’ve been involved in with CollabNet. Why don’t you give our audience—let’s start off with this. There may be people out here who, just as they didn’t know CollabNet, maybe they’re not familiar with the term “value stream mapping.”

    Robertson: Yeah. It’s very interesting. Value stream mapping is actually an older concept. It’s part of the Lean management framework. For example, many may have heard about Toyota. It was started there, as far as best practices around mapping material and information flow and how could we apply to, for example, the value chain, and pretty predominant in the manufacturing domain. And it’s kinda of interesting because I have a background in software engineering and I have degrees in computer science and engineering, but my first job was actually in architecture—not in software architecture, but actually designing building. CAD design.

    And it was interesting that, during that time, they started talking about design patterns and best practices, as far as architecting and putting together systems and designing. And I said, “Wow, this is very similar concept to what I learned back in college, when I was doing software engineering, software design.” And, very soon, that started translating into object-oriented and design patterns and things of that nature. So it’s interesting how patterns and techniques that were very popular and used in other domains, like manufacturing and architecture, now being applied to software. In other words, software is maturing, right? The software development process is maturing. It’s starting to utilize these type of practices.

    And the value stream map is just an example of that, right? It’s Lean management method for really analyzing that current state and designing a future state, based upon a series of events that take a product, a service, from its beginning through to its customer. Right? And, again, like I mentioned, Toyota—this is known as that material and information flow mapping, and it can be applied to any value chain, for example, right? And what is a value chain? It’s just a set of activities that take, for example—that delivers a valuable product or service to the market, right? So you got, in the manufacturing world, this was machines that did it; in the software world, it’s now tools that we use to deliver a product from a planning all the way to its operations stage.

    Shimel: Yep. Got it. So, Eric, this is something, obviously, that you have written and you’re talking a lot about it. Can you tell our audience, if they want—maybe if they wanted to find out a little more, where can they go? Before we dive in more than that, maybe where can they get more information on this?

    Robertson: Yes. Actually, they could come out to our website, collab.net, but, also, I recently published an article around how value stream mapping delivers a better DevOps tool chain, and we can post those links—I believe it was also on devopsy.kinsta.cloud and we have one that was delivered through TEDxBeacon, so there’s a series of outlets, and we’ll post those links there on where they can get more information about this.

    Shimel: Excellent. You know what? We’ll, for sure, do that. And then, Eric, you had also mentioned that you guys were doing some sort of roadshow or a little city tour, where you’ll be talking about this, as well as other areas of interest around DevOps and what CollabNet’s doing. What’s going on with that?

    Robertson: Yeah, so we’re actually having a series—we’re also doing it through webinars, but we’re also doing it through seminars, and we’re gonna be having these seminars throughout the different series. And, basically, what we’re doing there, what’s really critical there, is that we’re going to be not only talking about the value stream as far as more of the how this applies into the DevOps—in DevOps world, but also we’ll have customers there talking about how they are leveraging value stream mapping and how they’re mapping that to their tool chains and how they’re able to, from bare, start applying measurement, which, to them, is what they’re calling “the last mile” of DevOps, right? And it’s really—they’re gonna talk about how that provides a window to allow them to monitor, measure, improve their workflow processes, all around a series of KPIs, both velocity KPIs and also quality KPIs.

    Shimel: Mm-hmm. Excellent. So, again, I think, Eric, what we wanna do is post a—maybe if you have a schedule of cities that we can post with the notes from today’s show.

    Robertson: Yes.

    Shimel: I think that’s the way to do that. So—

    Robertson: Yeah.

    Shimel: —let’s return, though, for a moment, to value stream mapping and kinda dig in here a bit. One of the things—and, again, as we spoke about off mic, I’ve had some experience with value stream mapping—one of the things, though, in speaking to potential customers of value stream mapping, is it’s easy to say, “Oh, yeah, that sounds good.” Right? “Oh, that’s something we wanna do.” Okay, well, let’s schedule some time and I’m gonna need the right people at the table because, if you don’t have the right people there, it’s very hard, number one, to truly map out the value stream and, number two—

    Robertson: Exactly.

    Shimel: Right? And harder than that is let’s get some consensus on what we’re gonna do to make it happen.

    Robertson: Exactly.

    Shimel: You know, unfortunately, it can’t be some developer who raises his hand and says, “I really wanna make a digital transformation here and I need to convince my CIO. Can you come in and give me a value stream mapping kind of session or workshop or can we discuss it?” It’s not a one-man show.

    Robertson: Exactly. Exactly. And it is very interesting you said that because, because value stream looks at the lifecycle from planning to operations, there’re different stakeholders, right? And what’s happening in, especially in enterprise, is these stakeholders now—they have implemented the tools or they have guys that work for them or folks that work for them that implemented these tools, and they’re starting to ask questions or they already started asking questions around value. What I mean by that—you have the executive and he’ll say, “You know, my folks are telling me we did four deployments today.” Great. What does that really mean for the business?

    Shimel: Yeah.

    Robertson: Did we get little features out to the business, where they get utilized? Are they utilizing that? Did I actually place the right emphasis on those features? Right? The last release that I deployed on time, at least from a developer perspective, said I deployed this, I deployed it on time, but I’m having this increase of service desk tickets. What’s going on here? Why am I being called? Right?

    Shimel: Yeah.

    Robertson: And I _____ –

    Shimel: Oh, yeah. Exactly.

    Robertson: Right? [Chuckles] And it means that the IT office guys, right? They have their own set of—type of metrics that they’re looking at, right, and they wanna understand, right, “Is there anything impacting this release?” and without having to chase down and talk to every other person or look into every tool, to try to gather this information, right? And then you’ve got the engineers, like the QA engineers, and now compliance, security’s coming into play as well, right?

    Shimel: Absolutely.

    Robertson: So now folks wanna know, “Before I deploy, did all this pass through the quality gates? Was this sufficient?” Right? “What about security and compliance checks? Can I automate that feedback? Can I get that feedback to the appropriate stakeholders?” Right? So they’re already involved in asking these questions, but they really don’t have any direction there on how to get that information. And this is where—this is the impetus to say, “Well, you know what? Now’s the time to start looking at these tools, where you’re gathering this information, what’s generating this information flow, and how we bring this together.” Right? So it kinda starts to endow that value stream mapping conversation pretty well.

    Shimel: Yep. Excellent. Excellent point. Because, like DevOps itself, value stream mapping is a team sport, right? And—

    Robertson: Yep.

    Shimel: And it’s cultural and you need that group kind of involvement to make it happen. So, Eric, I’m sure you probably have a few war stories around this, though. Can you share with us sort of—you know what I always say? You learn more from your failures than you do from your successes.

    Robertson: Oh, my God.

    Shimel: Can you share with us maybe some value stream mapping engagements that didn’t work out and, of course, only if you’ve learned something from it, and what was the valuable lesson you learned?

    Robertson: Exactly. I mean, that’s—it’s very interesting that you said that because we had one customer—and I can even use it from my experience. I mean, I worked at a company and I used to dread Wednesday mornings because Wednesday mornings was—wasn’t really a scrum meeting, but it was more of a meeting as far as, “What is the latest status of this release that went out the previous day?” because we did weekly deployments,  weekly deployments. And everybody would dread that because it was really no place to go to get a full understanding that, “Well, if this release actually was deployed, what was in that release? If it wasn’t deployed, what was the bottleneck in there?” Right? “Was it that it failed a certain testing that it didn’t get through or did we discover that, in this environment, we did some monitoring and it didn’t pass this stage?” We had no idea. I mean, did the builds fail? Why? There was no insight to anywhere in that chain, right, from the planning, ’cause it’s all kinds of activities that are happening in the coding, the building, the testing, the deploying a release.

    And so, if you don’t really have an idea, as far as that information flow in a place where you can go and view that information and quickly understand “What are my exceptions, right, that I need to quickly identify and quickly address?” everybody’s chasing their tails there. And I’ve been on so many projects where that transpired and happened. And so this was really impetus of why we wanted to start having—start putting—leveraging this best practice, leveraging these practices, and then the tooling becomes more secondary type of aspect, rather than primary goal for driving processes.

    Shimel: Yeah, I agree with you. The tooling then winds up taking sort of a backseat to it. So let’s—well, we’re almost out of time, unfortunately, Eric. As I mentioned to you, the 15 minutes goes quick. We do the best we can.

    Robertson: No worries.

    Shimel: Let’s put—

    Robertson: I’m enjoying it.

    Shimel: —value stream mapping to the side a little bit. What else is—

    Robertson: Sure.

    Shimel: What else is going on with CollabNet?

    Robertson: So CollabNet is also partnered with a company called “Clarive”—it’s release automation software—and what we’re doing is is that we’re linking the release automation capabilities into our value stream management platform. Now what’s nice about this is that this allows us, very quickly, to start getting metrics across different type of applications and projects. And what I mean by that is, if you go into a larger enterprise, for example, they – of course, they’re experimenting with container type technology and Web-scale IT technologies, but they’ve also got some legacy applications, right? There may be Java, right? There’s—or on WebSphere or a traditional type of applications or architecture. They may even have mainframes or they may even have package apps, right?

    So one of the things that we’re doing is that we’re getting—we’re creating this abstract _____ layer around all those tools, so customers can have, enterprises can have a common user experience around release automation, whether or not—so, again, we’re abstracting the tools, so you’re focused on the process, and it doesn’t matter what tooling is utilized underneath. If it’s Webscale IT technologies, container-based technology, it does not matter. You can basically have a common release process across your different type of applications—package, legacy, and traditional—so we’re very excited about that.

    Shimel: Excellent. Sounds very cool. Eric, we’d love to talk more to you about this, but we kind of are over time. What I’d like to do, though, is maybe invite you back and we can talk. You know, we’ll leave value stream mapping for a moment and we’ll talk about other stuff next time, but I think we’d like to hear what’s going on in the world of DevOps, obviously, and with the players in it, and CollabNet has certainly been on the scene here and lots to tell. Until then, though, it looks like we’ll call it a wrap on this version of DevOps Chat and we’ll speak to you soon, and I—Eric, we’ve gotta get those links over. There’ll be in the notes for people who are listening in. But until then—

    Robertson: Great _____.

    Shimel: Eric Robertson, VP of product management and engineering at CollabNet, thanks for being our guest on this episode of DevOps Chats.

    Robertson: Thank you, Alan. Glad to be part of this.

    Shimel: My pleasure. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening in today and we hope to see you soon on another DevOps Chat. Buh-bye.

    — Alan Shimel

  • DevOps Chat: Puppet Extends Enterprise Credentials with Michael Olson

    DevOps Chat: Puppet Extends Enterprise Credentials with Michael Olson

    Puppet made three major announcements today around new versions of their flagship products, new products independent of Puppet Enterprise and a major expansion of partner programs and offices in the face of record growth over the last 12 months. As I detailed in my article on these announcements, these 3 taken together paint a clear picture of a market leader solidifying its position as an enterprise DevOps solutions provider. I had a chance to speak with Michael Olson of the Puppet product team about what these announcements mean.

    As usual, the streaming media player of our conversation is below. The transcript of our conversation follows immediately below (transcript will be updated shortly)

    Streaming Media

    Transcript of our Conversation

    Alan Shimel:                Hello everyone. This is Alan Shimel, Editor in Chief of devopsy.kinsta.cloud and we’re here on another DevOps Chat. Very happy to be joined on this episode of DevOps Chat by Michael Olson from the Puppet Product Team. Michael, welcome to DevOps Chat.

    Michael Olson:           Thanks Alan. Thanks for having me. Good to be here.

    Alan Shimel:                Pleasure. Pleasure to have you here Michael we always – actually we’ve had more than several people from Puppet over the years appear on DevOps Chat and we always – that’s always a great conversation.

    But today Michael you’re on here regarding several news announcements that Puppet put out recently today on May 11 and wanted to kind of go over them with you and cue our audience in to what I think are several major announcements coming kind of down the pike from Puppet.

    So if it’s okay with you Michael, you know the news as well as I do, do you want to lead off with what you think is the most important one or do you want me to pick?

    Michael Olson:           Sure, I’m happy to dig in. And today’s been certainly a pretty big day at Puppet, we’re pretty excited to announce a very significant set of investments that we think really continues to deliver on our mission of empowering IT to deliver better software faster, so looking forward to digging in to what that entails.

    It’s really around new products that help IT manage the complexities of their evolving and modern infrastructure as well as updates to some of our existing products that give really IT better control and situational awareness for the software that they deliver and run.

    And then new partnerships and company investments that are really focused on ensuring that Puppet is where our customers need us to be, that our customers and our community and ecosystem really have the talents and the support needed to scale their success wherever they are, so looking forward to digging into it with you.

    Alan Shimel:                Okay. So if you don’t mind Michael I’d like to start off with the announcements around new products – Puppet Cloud Discover – and if I mispronounce it I apologize – Lumigon? Is that how you pronounce it?

    Michael Olson:           Alan, you nailed it. Well done.

    Alan Shimel:                Okay. Well every once in a while even a blind squirrel finds a nut. But anyway, so we have Puppet Cloud Discover and Lumigon – and these are offerings in the container and cloud native technology areas, but beyond that Michael why don’t we dig in a little bit. What exactly is Cloud Discovery first?

    Michael Olson:           Sure. And you’re exactly right. And I think before we dig in it’s useful just to set a little bit of context Alan and I’ll start by saying that our heritage really at Puppet has been rooted in helping IT professionals cope with sort of the complexity of managing an ever-growing infrastructure and application estate really by kind of harnessing automation.

    So for more than a decade our core focus has really been around helping our customers define a desired state model for their infrastructure and applications and then providing an engine that translates that desired state of how they want their infrastructure and applications to look into reality.

    So that has benefits of doing things like preventing configuration drift and eliminating manual intervention from the software delivery process.

    And one of the things that we’ve seen is – you know, over the course of this journey over the past 12 years is we’ve been very fortunate to be supported by a passionate open-source community that’s helped refine our offerings, coving every aspect of systems management so that our new users that are getting onboard with Puppet can hit the ground running so to speak as opposed to having to start from scratch.

    And so in light of that we are making investments to better support that journey for our customers and answering some of the common questions that we’re hearing from them. Things like, “How do we get started with automation and modeling?”

    And one of the most common starting points that we see our customers looking to solve for is just know what software they have running across their datacenter and their cloud and container environments: answering a simple question of, “What resources and applications do I have running today? How do I bring those resources under management?” And I kind of refer to that general category of problems as discovery

    So what we’re announcing today is really a new set of investments and offerings that are intended to give IT teams much better situational awareness into what they have running across their application and infrastructure estate regardless of whether that’s running in the cloud, in containers or on their traditional on-premise datacenter.

    Alan Shimel:                Got it. Got it. So Michael I think that kind of explains a little bit what Cloud Discover is – Puppet Cloud Discover. And I’m looking at these two names of Cloud Discover and Lumigon – I’m reminded back to my days at one of the security companies I helped co-found – Still Secure – but we always had this sort of battle between descriptive names or kind of catchy marketing type of names.

    And when I look at Puppet Cloud Discover that’s certainly a descriptive name, right? I think you almost get what it is from the title and it obviously fills a real need in the market as we get these – I guess you call it cloud sprawl – of an ever-expanding infrastructure and understanding what we’ve got there.

    Talk to me a little bit about the other one though, Lumigon. How did we come up with that name and what does it do?

    Michael Olson:           You bet. Yeah, Lumigon is a new offering from Puppet. It’s open-source so it’s something that is available for our community as well as anyone who is responsible for managing containerized environments within their organizations to go to our website and just simply pull down and start using today.

    And I think as we all know containers have really emerged as a new and common way of packaging applications with that container image being the artifact that’s handed off from development into operations, and we think containers represent a really big opportunity for orgs that want to accelerate their product delivery.

    But today what we’re often hearing is that those container environments are largely black boxes from an operational standpoint. What’s more, since there’s so many of them, containers tend to be ephemeral, so to speak, they tend to have shorter lifespans than VMs and that brings a whole set of challenges where you’re looking at bringing containers into production environments.

    So what we’ve announced today is a new offering. It’s open-source and free and available for anyone to go and pull down and start using of Lumigon which is an offering that really focuses on discovering what’s running inside all of those container environments and giving operators really better visibility and control around their container estate.

    So because this Lumigon effort is an open-source tool that can analyze applications – you know, we’re initially targeting docker containers and exposing application metadata about those but certainly looking at extending that over time as we continue to get feedback from the community.

    Alan Shimel:                Great. Now Michael over the years we’ve spoken to several Puppet people – among them Gareth Rushgrove, D-Pack, Sonja himself – and we’ve talked here at devopsy.kinsta.cloud about Project Blue Shift at Puppet which is kind of, as you probably are well-aware – Puppet looking at new technologies and making sure that they – that Puppet’s mission encompasses working with these new technologies.

    Is Lumigon something that maybe comes out of Project Blue Shift or independent of that?

    Michael Olson:           I think it really represents a common vision from Puppet which is you know we see a lot of organizations in our customers that are really looking to automation as a bridge to their future. As organizations look to modernize physical infrastructure and move it into the cloud, adopt containers in production environments they’re looking to have automation really baked in from day zero as they look to do that.

    And so Blue Shift is, as we’ve talked about in the past, really represents Puppet’s vision for helping our customers adopt the cloud and containers in consistent, repeatable and reliable ways. So it encompasses things like using automation to install docker or lay down operating environments in docker, for example, as well as do things like define and deploy the services that run inside of docker containers giving our customers really better portability to be able to kind of lift and shift workloads that they may have defined and are running on virtual infrastructure, for example, and getting that running in containers without having to adopt platform-specific tooling to do so.

    Alan Shimel:                Make sense. And certainly – I mean I’m fresh out of Docker Con two weeks ago now – it seems like two weeks – maybe it was last week – but in any event I mean the shift to a containerized application infrastructure is well underway and so a product such as this obviously I think should find a ready market and the fact that it is an open-source tool and everyone can get involved.

                                        Michael what is – or other – I know it’s early in the game but are there any plans to have an Enterprise or pay-for version of Lumigon out there?

    Michael Olson:           You know it’s certainly something that we’re looking at longer-term is as we continue to build off of this foundation, you know, ensuring that we’re meeting the needs of our large Enterprise customers as well as the broad community of more than 36,000 organizations that rely on Puppet technology today to deliver and operate their software

    And I think what we’re focused on right now is really making sure that we’re nailing that core set of problems with a sledge hammer which is, “How do I expose the black box and know what’s running inside of my container environments so I can do things like identify if I’m vulnerable to a potential CVE or if I’m vulnerable to a bug in a library dependency. You know, to know if for example my OS standards are being followed and adhered to within my organization.” These are the types of questions that Lumigon will help users answer today.

    And then shifting to the Cloud Discovery announcement that we talked about briefly earlier we’re also introducing a new offering here at Puppet that’s really focused on giving IT teams better situational awareness into what’s running in their cloud infrastructure specifically in AWS.

    And so it’s really focused on helping IT teams go back and discover all of the resources and applications that are running in AWS. This is a limited preview that we’re offering for Cloud Discover today really to give those teams a better sense of what they have running in the cloud so they can make better decisions about how they want to bring them under management through automation.

    Alan Shimel:                Great. So Michael both the Cloud Discover and Lumigon in some ways are maybe the cabooses on the engine here with the announcement of a new version of Puppet Enterprise – or at least the availability of a new version of Puppet Enterprise.

    Why don’t you tell our audience a little bit about that?

    Michael Olson:           Sure, yeah. So Puppet Enterprise – we’ve introduced a new version, we call it 2017.2 per our naming conventions – and I’ve been at Puppet for a few years now and in my opinion it’s really not an exaggeration to say that it’s one of the more significant releases that we’ve had in several years, really with a focus on giving our customers better visibility into the software that they have running on premise in their datacenter no matter how they’re managing it, as well as easier, simpler tools to be able to orchestrate deployments and run deployments across infrastructure and applications using visual workflows.

    So the first set of innovation that we’ve introduced into the latest version of Puppet Enterprise is really around being able to inspect software packages that are running across your datacenter.

    And one of the areas of feedback that we frequently hear from IT teams is it’s hard to know what software packages are running across their infrastructure, what versions they’re running, for example, in order to easily identify packages that may be vulnerable to security risks.

    So we’re introducing some new reporting for our Puppet Enterprise customers in this version that’s really focused on giving IT easy visibility into the software packages that they’re running regardless of whether they’re being managed today by Puppet in order to really provide that insight to identify potential security issues a lot faster

    And then as our customers look to use automation in order to drive change across their software stack we’ve also introduced a whole set of orchestration capabilities over the course of the past year-and-a-half. With this release we’re extending that to the Puppet Enterprise Web UI essentially giving our customers the ability to define, run and monitor deployment jobs entirely using visual workflows within the Puppet Enterprise Web UI.

    So it’s easy to do things like define a deployment job, target a specific portion of your infrastructure, run a phase deployment for doing things like canary workflows, and then monitor the status of that deployment in real-time so if things aren’t going well you can hit the stop button, investigate, tinker as needed and then restart that deployment; so giving our customers a lot more flexibility into how they drive change across their software.

    Alan Shimel:                Fantastic. And I love the naming conventions here – I remember speaking earlier about it – I think it makes it easy for people to see where they are and what they have – but the simple naming kind of hides the fact that there’s a lot more punch in here. And by the way, that’s available now Michael?

    Michael Olson:           Correct, it is. Yeah. It’s available today for – certainly for current Puppet Enterprise customers – and for anybody who’s new to Puppet out there you can simply go to our website and pull down a copy, it’s free to try on up to 10 different servers, devices or applications.

    Alan Shimel:                Sure. Michael, and I didn’t ask this – my apologies – for the Cloud Discovery and Lumigon – what’s their availability?

    Michael Olson:           Yeah, Lumigon, which is really around, again, kind of exposing the black boxes of containers, is – that offering is available to try today and you can find a way to get there directly from our website at Puppet.com. And then the Cloud Discovery offering is available as part of a limited preview so what we’re really looking to do is if you’re interested sign up through our website and we’ll be in contact with you if you’re interested to discuss next steps.

    Alan Shimel:                Perfect. Next Michael let’s talk a little bit about the last announcement today, and this one was more around sort of momentum – it looks like a bunch of new Enterprise customers added as well as new locations and partners and partner offerings. I don’t know if I left anything out but give us some of the details there if you can.

    Michael Olson:           Sure, yeah, happy to do so. And you know you get this Alan, obviously you and I have talked before, but what we’ve really seen over the course of the past several years is just a huge surge in growth and momentum for Puppet and I think it’s been fueled by growing demand in the market for dev-ops and for digital transformation.

    So we’re really taking that momentum and using it to grow more aggressively and really help our customers be more successful, you know, laying the foundation for dev-ops wherever they are in the world.

    So what we’ve also announced today is a new set of partnerships with organizations like AWS and Cisco and others as well as global expansion for Puppet: we’re opening up new offices in Singapore really to better serve the needs of our customers internationally and ensure that Puppet is with them wherever they are and however they want to engage with us.

    Alan Shimel:                That’s great. What about from a partnership point of view though? Any new partners to announce or just partner offerings?

    Michael Olson:           Yeah, from a partnership perspective – I’ll touch upon a couple things – one of which is we have a new marketplace offering up on AWS that we also made available today and really the key takeaway there is as our customers are increasingly looking to kind of recognize the value of cloud-based environments – they’re using AWS – we’ve really deepened our relationship with Amazon Web Services and deepened that partnership with a new offering that basically makes Puppet Enterprise available on the AWS marketplace on an hourly pay-as-you-go basis.

    So it’s really focused on simplifying the installation of Puppet Enterprise and providing a way of securing configuration and getting better visibility into your AWS infrastructure through Puppet directly from within the AWS marketplace.

    Alan Shimel:                Yeah. You know, to me Michael that’s a huge winner, right, because number one – I’m familiar with the AWS marketplace and there’s no lack of solutions up there – but once you’re in there and you have the ability to kind of piggyback the AWS billing, if you will, for hourly service and hourly offerings – it allows people to consume their services in the manner that they’re used to consuming them in AWS, right?

    I think early on there was a big rush to the AWS marketplace but if you weren’t truly integrated into AWS it just, you know, from a billing perspective and usage monitoring and all that, it – I think their customers just did it – it was just too clunky frankly, right? So this makes things a lot smoother in you’re an AWS customer.

    Michael Olson:           I think that’s spot on Alan. Like the constant feedback that we hear from our customers is they want us to meet their needs and engage them how they want to be engaged, so to speak, and I think this is a marker that helps payoff that objective that customers have is, you know, if you’re looking to bring automation into your cloud environments – you know, looking to get started for the first time – just, you know, click a few buttons and spin up Puppet directly through the AWS marketplace.

    And we’ve also really extended our partnership with Cisco in some of the partner-related announcements that came out today as well as we see more Cisco customers that want the power of Puppet as a way of defining, deploying and operating all of their software. So with our expanded partnership joint customers of Puppet and Cisco can now buy and get support for Puppet Enterprise directly from Cisco and any Cisco value-added reseller.

    Alan Shimel:                Cool. Very cool. Okay. Michael, you know, I promised you we were going to do 15 minutes and here we are for over 20 – I apologize – but before we wrap things up did we miss anything in the announcements?

    Michael Olson:           I don’t think so Alan, this has been a great conversation and I think we touched upon most of the highlights.

    Alan Shimel:                Yeah, I think so too. You know not everything fits into a 15-minute bucket though in life so I apologize but I think it was well worth the time spent digging into these new, exciting developments and announcements over at Puppet.

    Michael Olson from the Product Team at Puppet thanks for being this episode’s guest on DevOps Chat. Hope to have you on again soon.

    Michael Olson:           Likewise. Thanks for having us Alan and it’s always great to catch up with you.

    Alan Shimel:                All righty. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for listening everyone and we’ll see you on another DevOps Chat hopefully very soon.

    — Alan Shimel

  • Puppet Solidifies Enterprise Provider Status With Bevy Of Announcements

    Puppet Solidifies Enterprise Provider Status With Bevy Of Announcements

    Puppet has been maturing from a company with an enthusiastic base of users of an open source tool, to a leading provider of enterprise DevOps solutions for the last few years. Things really accelerated with the appointment last year of Sanjay Mirchandani, as CEO and the group of experienced, A+ players he brought to the executive team. Today Puppet took another step towards solidifying their position as a leading provider of enterprise DevOps solutions with a string of news announcements highlighting new products, accelerated growth and new/expanded presence.

    Lets start with what for many of you will be the most important. Puppet today announced “the general availability of Puppet Enterprise 2017.2, and upcoming availability of Puppet 5 Platform, the latest version of Open Source Puppet.” I had a chance to chat with Puppet CTO Deepak Giridharagopal, Chief Product Officer, Omri Gazitt and VP of Marketing, Tim Zonca. In their considered opinion this new version of Puppet Enterprise, more than just another upgrade, may in fact be the most significant upgrade to Puppet ever.

    From the press release, the most significant of these new capabilities are:

    • Package inspection: Users get started with automation by quickly identifying packages that aren’t being automatically managed, but should be. With package inspection, Puppet Enterprise users report on unmanaged infrastructure, making it easy to see the systems that would benefit most from automation to ensure their most critical software has the right maintenance updates, security patches and licenses.
    • Visual orchestration workflows: Users orchestrate infrastructure and application deployments entirely from within the Puppet Enterprise web UI, without writing a single line of Puppet code. Enterprises can target specific infrastructure environments using drop-down menus and filters, define workflows, monitor deployment status in real-time, and start, stop or restart deployments as needed, all with the click of a button.

    Both of these are much deeper than the few words from the press release. In addition to these though, there are also even more new capabilities packed in to 2017.2. Additionally, the open source Puppet platform 5 has many new innovations and hooks that will continue to keep the large base of open Puppet users happy, if they don’t require or need the greater feature set of the enterprise version.

    Speaking of those many users, that is the lead in to the second announcement. Puppet is growing and growing fast. Over the last 12 months they have added more than 250 enterprise customers to the business. Today over 37,000 companies use Puppet, with over 75 of the Fortune 100 also relying on Puppet. To help satisfy this increasing demand, Puppet announced the opening of a new Asia-Pacific office in Singapore, a large expansion of their existing office in Sydney and the opening of a new R&D center in Seattle.

    Puppet also announced significant additions to its partner program and participants:

    • New AWS Marketplace offering: As enterprises continue to recognize the value of cloud-based environments, they are turning to AWS and other cloud platforms for efficiency, savings and scalability. To support cloud efforts, AWS and Puppet deepened their partnership, making Puppet Enterprise available on an hourly, pay-as-you-go basis. The new offering simplifies installation, provides secure configuration and delivers immediate ROI.
    • Extended Cisco partnership: As software defined networking continues to evolve as a key tenet of the modern data center, Cisco customers want the power of Puppet Enterprise as a unified way of defining, deploying and operating all the software they run. Joint customers can now buy and get support for Puppet Enterprise directly from Cisco and any Cisco VAR.
    • New partners for security and DevOps: Puppet has added a number of important partners as part of its inaugural class to the Technology Alliance Partner Program (TAPP). By collaborating with F5, Splunk, Cumulus Networks, CloudPassage, Conjur, CyberArk, Onyx Point, Intelliment and Sensu, Puppet and its partners collectively deliver a better architecture around security and DevOps.

    Again, all signs point to Puppet’s ascendence to enterprise provider status as it matures into its market leader position.

    The third and final announcement from Puppet is by no means the least of the three. In addition to the first two announcements, Puppet also announced two new offerings, Lumogon™ and Puppet Cloud Discovery™. With these the company expands its enterprise offerings beyond Puppet Enterprise, empowering companies to overcome challenges associated with modernizing infrastructure and application stacks.

    These are first offerings independent of Puppet Enterprise offered by the company. The represent significant new capabilities in two quickly growing markets, cloud and containers.

    Lumogon empowers “anyone involved in running containers, like site reliability engineers (SREs), release engineers, DevOps engineers, and the application developers themselves, now have a tool to gain operational insights into what makes up their containers with Lumogon. Lumogon provides a transparent window into each Docker image and running container, and offers a way to collect, query and report on container application metadata.”

    “Puppet Cloud Discovery collects and visualizes a rich set of system data to give users better awareness of the state of their infrastructure. Unlike other tools on the market that were built for traditional on-premise infrastructure, Puppet Cloud Discovery is cloud-first and is designed to model ephemeral cloud infrastructure. Puppet Cloud Discovery is delivered as a service, making it easy for users to see immediate time-to-value.”

    So Puppet has raised the bar and solidified its position in the marketplace. When taken together these three announcements illustrate that Puppet is accelerating in almost every facet. It will be interesting to see how they continue to build in the months and years to come.

    — Alan Shimel

  • ChatOps: Has the Fat Lady Already Sung?

    ChatOps: Has the Fat Lady Already Sung?

    One of the sometimes unsung stars of the DevOps scene is ChatOps. I have heard lots of folks use the term, but what does it really mean to you? ChatOps is a phenomenon that started, perhaps not surprisingly, inside of GitHub. It was only natural that developers leveraging the repository to share and build better code would eventually start collaborating in ways that other messaging options just couldn’t provide.

    Whether ChatOps in GitHub is something that gave rise to the growing enterprise collaboration and chat  product/services market is open for debate. There is no doubt, however, that the 30 (give or take) cloud-based messaging and chat platforms out there today are looking to make their mark in the world of developers, engineers, admins, DevOps and IT professionals. Some of the larger players in the space have already launched features designed specifically to appeal to this set of users, with Atlassian HipChat and Slack among the leaders. But they are not alone. I thought it would be worth the effort to take a look at some of the players and up and comers in the space.

    HipChat has been a strong proponent of ChatOps for a time now. The company has consistently been tagged as a leader and boasts product integrations with many different tools and services. For example, a Puppet integration brings the power of ChatOps to joint HipChat/Puppet DevOps customers. Slack has made strides as well. Integrations with incident management and response providers including VictorOps and PagerDuty are only a few examples of how Slack has given teams the ability to collaborate on and fix problems with just a few clicks.

    Despite the millions of users already using Slack, HipChat, Microsoft Teams, Facebook Workplace and other apps in the market, there is still no definitive proof of whether any of the competitors have won the hearts and minds of the IT professional. In fact, we are seeing many of general IT publications writing about several of these tools because many of their users are in that category. The original ChatOps tool that was brought to life in GitHub, for all we know, may still be king among the IT audience.

    Will the Jury Reach a Verdict?

    There are two things that are certain in the market: The jury hasn’t yet decided if there is a ChatOps winner among the numerous options, and developers and other IT professionals may want to consider other options before reaching a decision. Unfortunately, for as much as the true IT practitioners despise marketing, there simply has been no way to avoid the  buzz that the aforementioned providers have created. Chances are, if you are searching for a solution, one of the biggies is going to pop up in the top of your browser and potentially block you from finding all options available.

    The Choice Gets Tougher

    The foundational similarity between top platforms is that they use cloud-based applications to connect teams in efficient, collaborative and transparent ways. Mobile workflows and the growth of BYOD has increased the popularity of enterprise messaging and chat platforms as they create ways for employees to quickly reach one another on their own terms. Yet even so, enterprise messaging vendors are learning that  to be effective, they must also provide users with agility, security and the ability to execute on change.

    Options to Consider

    The past couple ​of year​s​ have highlighted just how competitive this space is, and how quickly it is moving. If you work in an environment that leverages ChatOps or are considering ChatOps options, the list below presents a few of the lesser-known or up-and-coming platforms out there with the potential to become your ChatOps solution. That is not to say that the big guys such as HipChat or Slack are not worthy. On the contrary; they are great solutions. But some of these others might be worth looking into:

    Newcomer Flock entered the U.S. market in September 2016. With an eye on the developer community, the startup worked quickly to open its API to developers and has started adding integrations with partners such as PagerDuty, Bitbucket and Appsignal. Flock’s biggest differentiator is that it allows developers to build bots, widgets and apps on its framework using Java and Node.js SDKs, which easily feed into Flock’s Appstore for distribution. Flock allows developers  to spin up applications in just days. For developer teams stretched on time and budget, they’ll find the application has GitHub integration, engages quickly after being turned on and offers low costs for its paid version.

    Ryver, founded in 2015, provides all-in-one team collaboration, from chats, posts and files to the option to invite as many team members and guests as needed. Additionally, Ryver has a broad range of functionality that offers the ability to share long-form posts or threaded discussion, and integrates with the likes of Google Docs, Dropbox, Asana, Jira, Twitter and Facebook, among others. Ryver recently rolled out its “Global search” bar, which allows a keyword search to locate multiple matches across conversations and solves email’s common problem of archiving data.

    Third, there’s ChatWork, known as a group app for global teams. ChatWork is available in five languages and says it supports 124,000 customers in 205 countries. Last month, ChatWork announced new features to connect multiple chat platforms through the ChatWork desktop app as well as a new screenshot feature. The multichat and chat service integration features allow users to be logged into multiple ChatWork accounts without having to change browsers or log in and out repeatedly. This comes in handy when using multiple ChatWork accounts, such as personal and business accounts at the same time. It also allows teams that use Gmail, Outlook or Skype to use these services together from a single area within the desktop app.

    eXo Platform began as an open-source project in 2002 focused on implementing the industry’s first Java portlet container. The project grew into a company in 2003, to start working with its first customer, the U.S. Department of Defense. Today, eXo is an all-in-one open-source digital collaboration platform that provides knowledge, document and content management, social engagement and project collaboration tools integrated into your business’s applications. It is full-featured and extensible, and has a great design. eXo helps companies connect their employees, customers and developers through social, collaborative and content-driven intranets, websites and dashboards.

    Assembla is a set of cloud-based task and code management tools for software developers. Created in 2005, Assembla hosts more than 100,000 commercial and open-source projects and is used by more than 800,000 users in 100+ countries. With Assembla, software engineering teams can manage tasks, teams and code in one place with SVN, Perforce, Git repos, cardwall view of tickets for drag and drop planning, wikis and more. Integrations include Slack, Github and Zapier.

    Finally, there’s Salesforce company Quip. Quip was founded in 2012 by Facebook and Google alumni and combines documents, spreadsheets and chat into one experience. With Quip, enterprises can manage projects, finalize budget plans, share meeting notes and stay connected. Quip is used by thousands of the world’s most well-known and innovative companies, including Facebook, NewRelic, Quora, and Pinterest.

    As you can see, there are lots of choices out there if you have not already settled on Slack or HipChat, or if you want to see if something else is better for your situation. If you haven’t heard the singing, there is still time to check them out.

    — Alan Shimel

  • DevOps Chat: Taking Care of Your People with Rob England, IT Skeptic, DOES Speaker

    DevOps Chat: Taking Care of Your People with Rob England, IT Skeptic, DOES Speaker

    In this DevOps Chat we speak with Rob England, the IT Skeptic. Rob joins us from New Zealand (you have to love the internet). Rob is going to speak at this year’s DevOps Enterprise Summit London, June 5-6, about the importance of taking care of your people in the DevOps transformation process. Rob is always an entertaining fellow and this chat is no different. If you are attending DOES London this year, you don’t want to miss his session!

    As usual, the streaming media of our conversation is immediately below and the transcript of our chat follows that:

    Transcript of the Chat

    Alan Shimel: Hey, everyone. This is Alan Shimel from devopsy.kinsta.cloud here for another DevOps Chat. We’re lucky to be joined on this DevOps Chat by a friend of mine and a person who’s actually appeared before on our DevOps Chat, all the way from New Zealand: Rob England, the IT Skeptic. Rob, welcome to DevOps Chat.

    Rob England: Hi, Alan, and, hi, everybody. It’s a pleasure to be here.

    Shimel: So, you know, Rob, actually, I didn’t ask, but are you back home in New Zealand right now?

    England: I am, so I’m about to have my breakfast. [Laughs]

    Shimel: Okay.

    England: Tomorrow. Your tomorrow. So –

    Shimel: Yep, it’s my tomorrow. You’re already living my tomorrow—that’s interesting. So, Rob, of course, I think you’re well known within the DevOps community and the IT community at large, but, for anyone who’s listening may not be familiar, why don’t you give us a quick little background?

    England: Okay, thank you. Yeah, so I come from a service management background, so I have a bit of a presence internationally with a small blog that got a service management following, so that’s how I sort of became internationally networked. And, originally, I was a bit of a skeptic of the whole DevOps thing, but I was gradually turned, by Gene Kim and by John Willis and by Jez Humble and others, into a bit of an enthusiast, and now my whole life is DevOps, really. I consult here in Wellington, New Zealand to the DevOps community and I’m working with a couple of the largest government departments here in New Zealand now, helping them on their DevOps journey.

    Shimel: That’s just great. And, Rob, you’re traveling from New Zealand to London, June 5th and 6th, for this year’s DevOps Enterprise Summit, DOES London. It’s at the –

    England: I am.

    Shimel: – QEII Conference Center. And you’ll be speaking there as well.

    England: I am. Oh, I’m really, really pleased and honored to be selected to speak; I think that’s fantastic.

    Shimel: I think it is too. So, Rob, we’re lucky enough to interview a few other speakers from DOES—not only from London but in past DOES events in San Francisco, but can you give our audience a little bit of a flavor for what it’s like or what’s the process like or what motivates one to go speak at a DOES event?

    England: [Chuckles] Oh, in this case, what motivated me was Gene Kim, so I was talking to him about some of the people stuff that I’m quite passionate about, and he said, “Hey, you should write that up and submit it,” so I did. And, from there, it was pretty straightforward—I put all the details in and had my proposal accepted—so that’s very exciting. As I say, I’m very passionate about the people side of things and the cultural change, and the focus for this presentation is around taking care of our people through that transformation.

    Shimel: Excellent. And so, Rob, when you mention people like that, I’m reminded or brought back to a—I think it was Adrian Cockcroft’s presentation in San Francisco this past—don’t remember if it was October or November, but you may remember. And Adrian’s presentation was very much that,“Hey, people are your most valuable asset and you gotta treat them right. And, when you think about the money you spend on tools and all of these other things, it pales in comparison to the importance of spending money on people.”

    England: Yeah. Absolutely. In the past, even before my DevOps life, I used to write about how, if you look at any project, when we’ve had projects, and how the money was allocated within that project, if it wasn’t sort of one-third people, one-third process, one-third tools, then you had a very strong indicator it wasn’t gonna be a successful project.

    Shimel: Mm-hmm. Repeat that again, though, ’cause you know how you New Zealanders are – you talk so fast. [Chuckles] That it was one-third, one-third, one-third?

    England: Yeah, yeah, yeah. So one-third people, one-third practices, one-third tools. If it’s not something like that, it’s very typical to see project proposals that are going to spend 50 percent of their money on installing the tools and 50 percent of their money on redesigning their processes—oh, and, by the way, there’s a day’s training. You know, and it’s like, well, there’s nothing else recognizably about workshopping with people or collaborating with people or, you know, coaching people or all the other people aspects. It’s very common to see projects that are not planning to spend any money on all that, and I think that’s a –

    Shimel: I agree.

    England: – a formula for failure, right?

    Shimel: Yeah, no, it is. I mean, we tend to take the people part of it for granted, and, just as you said, you don’t spend the money on it, will spend a ton of money on tools and infrastructure. Right?

    England: And I have to say, I think that’s one of the two primary reasons why service management initiatives were so often unsuccessful, was that, I thought, didn’t coach us enough to focus on the culture and the transformation, and we spent too much time on process, so DevOps—for me, the power of DevOps or a big part of its power is it’s focused on people and culture.

    Shimel: I have to agree with you. I have to—you know, Rob, I’m reminded of, back in my security days, the co-founder of StillSecure, I went to visit a rather large bank out in New York, and it was about vulnerability management. And we were talking about the vulnerability management program they had in place and I mentioned to ’em that the way they were doing things, it was forcing his security team not only just to scan at night, which is, you know, normal, but to actually only do remediations on weekends.

    England: Mm-hmm.

    Shimel: And I said, “You know, that means that your security team is working every weekend, in addition to working during the week, ’cause you don’t have enough people to stagger that.” And he said, “I don’t care. I pay them by the week; I don’t pay them by the hour. I don’t care if they work seven days a week.” And that –

    England: There’s a good boss, eh?

    Shimel: Yeah, no, that’s someone you’d wanna work for, right? But this, unfortunately—you know, we talk about culture and the whole “Kumbaya” thing that many people kinda try to say with DevOps, but it’s real. You gotta treat your people as your greatest asset, and that was Adrian’s message, right, at DOES San Francisco. They’re not –

    England: That’s powerful.

    Shimel: Yeah. And they—if you treat ’em like crap, crap is what you’re gonna get, I’m afraid.

    England: Absolutely. And my particular focus for this presentation is about the effect of the transition on people in your organization and, in particular, there’s this “Get on the bus” thing, but we don’t wanna actually throw people under the bus, so it’s giving people the opportunity and the time to grow and to make the transition. There’s very often a “revolution, not evolution” thinking in management’s mind: “Are we just going to change everything?” And, again, we’re very neglectful of the fact—the old bell curve—we’re very neglectful of the fact that just because a few people are coming along doesn’t mean we—we still have to allocate more time for the great masses to get their head around this thing and absorb some of these really quite challenging and radical concepts that underpin Agile and DevOps—it does people’s heads in, as we say down here.

    Shimel: Yeah. So, Rob, let’s talk about that a little bit, if we can. You know, you’ve now consulted, as you said, with a bunch of government departments and companies, both in New Zealand and in other parts of the world. What, from a people point of view, what is the hardest things that these guys or these people have to kinda wrap their heads around to make it successful?

    England: Oh, I’m sure the biggest challenge is getting—well, actually, one of the biggest challenges is getting away from that silo-ed thinking, and so the other power of DevOps, along with its focus on people, is its focus on systems and systems theory and systems thinking. And so I think that they struggle to get out of their silo and start thinking holistically and seeing the whole flow of value and understanding their role in that. That is a big challenge to just about everybody.

    Shimel: Agreed.

    England: Then there’s also—yeah. And then there’s also peculiar challenges to each organization as well, right? So I’m thinking of one where a particularly psychopathic CIO had moved on, and it was trying to teach people that, “It’s okay now. You can come out from under your rocks, you know? It’s gone.” So that’s –

    Shimel: “Out from under your rocks.”

    England: Yeah. That’s a—they all sort of crawled away into shelter, you know? And so that’s the peculiar problem in one situation. So there’s—you know, every place has its own challenges, but a universal one is that siloed thinking and another universal one is just the letting go of the—do you remember the Bastard Operator from Hell, BOFH, or –

    Shimel: Mm-hmm.

    England: – or Dilbert‘s Wally? You know, these characters that—it’s considered funny in IT that people have dysfunctional behaviors and are misanthropic, and part of the DevOps message is just we don’t tolerate that anymore. That negativity is not allowed—we just don’t tolerate it—and getting rid of some of that old cynical bitter and twisted IT thinking is also a common challenge.

    Shimel: I agree. I agree. And you know what? I think part of it is not only the negativity from whether it be a supervisor or peer; I think the other biggest thing that I personally see and when I talk to organizations around DevOps and stuff, and not just dev and ops—when I talk with QA and security and management and so forth—is the finger-pointing, is the—it’s almost like American politics, I’m sorry to say, in that “Yeah, I know this is screwed up, but blame the other guy,” or “If you think this is screwed up, you should see how screwed up the other guy is.”

    England: Absolutely.

    Shimel: You know? “And it’s not my fault; I inherited a mess,” and all of this kind of thing where one of the refreshing things about DevOps is it started with the blameless postmortem, but it’s more than just a blameless postmortem—it’s about “Stop pointing the finger and let’s work on solving this together, instead of just saying, ‘Hey, it’s this mate’s fault and it’s his problem.’”

    England: “I’ve got your back.”

    Shimel: Yep. I mean, and that –

    England: I’ve got your back, buddy.”

    Shimel: You know, and that may sound hokey and “Kumbaya-ry” and  all that, but, really, I think that’s when you start building a team.

    England: There’s a really good cartoon, that might be a Paul Wilkinson one, where the ops guys are at one end of the boat, looking down at the dev guys at the other end of the boat, trying to deal with a fountain of water and saying, “Not my problem, not my end of the boat.”

    Shimel: Right. Uh-huh. Exactly. And we’re all on the same boat, though. So –

    England: Yeah. Yeah.

    Shimel: So this is a real thing. Rob, other than DOES, have you been talking about this kind of subject at other events and so forth?

    England: Oh, for sure. So, actually, it’s been an interest of mine since before I was consulting. I used to work in—for my sins, for a vendor, and I used to do work on professional development there and trying not to let the technical people fall under the bus and trying to get them to skill up to be consultants, rather than just product jockeys. So I’ve worked and talked in this field for a long time, just as a personal passion. I hate to see good people lost, you know, just because their organization failed to make sure they were coming along and to take care of them.

    Shimel: Sure. Sure.

    England: So that’s a long-term passion, but this particular topic now I’m hatching especially for DOES, to put together a presentation specifically about the DevOps implications of—it’s called “Surviving DevOps,” so making sure everybody’s—it’s not just that you individually survive, but that “no person left behind,” you know, as well.

    Shimel: I agree with you. So, Rob, geez, I’ve met you—wasn’t this year’s San Francisco DOES; it was last year’s. So it wasn’t 2016; it was 2015 DOES San Francisco. And we’ve, of course, seen each other several times since, but –

    England: And, you know, I’m one of the few people in the world who’s been to every single DOES in both the U.S. and the UK.

    Shimel: So I think I’m one of them too, actually, but –

    England: Yep, you would be.

    Shimel: Yeah, which is interesting, when you think about it that way. But let’s—I mean, many in our audience may not have been lucky enough to even get to one, let alone five or six of these things. Can you give our audience a flavor of why? Why do you keep coming back? Why did you feel compelled to wanna speak at this one? What makes this a great event in your mind?

    England: Well, I think it’s the fount of knowledge for DevOps, especially DevOps enterprise, so my interest is DevOps for hoses, not DevOps for unicorns. And, very much, the focus of the enterprise conference is around DevOps in the real world, DevOps in the enterprise world, so that’s the first thing. The second thing is that Gene does a fantastic job of focusing and coaching presenters to make sure that their presentations are really short and pithy and full of value, and they also make sure that the presenters are practitioners, so there’s not a lot of talking heads, except for some really high-value experts like John Willis and Jez Humble and Adrian Cockcroft, the people who are up there purely because of their intellectual strengths. But most of the speakers are there because they’re reporting back from the coalface about their own experiences and learnings, and so that, to me, is gold.

    Shimel: Yes. Any—well, I guess that kinda says it all, Rob. If anyone had any doubts about whether they’d wanna go to this or not, that clears that up. Rob, anything else happening exciting around DevOps you think people should be on the lookout for?

    England: Oh, well, I’m not sure about _____ – the value for me is that I live on the last rock on the planet, so I actually get quite a different lens on DevOps than perhaps those, like yourself, immersed in the big economies and big societies, and, certainly, it’s going gangbusters here. There’s a huge wave of interest in the mainstream—in government, in the airline, the banks—and I’m gathering that that’s not necessarily the case everywhere in the world, so, you know, I think that –

    Shimel: No, I think it is. I really think it is.

    England: Yeah. Yeah. But they’re not just dabbling anymore, right? They’re actually transforming; they’re restructuring the way they go. And, to me, that’s the excitement of the moment, is that this thing is mainstream. You know, it’s bridged the chasm. Remember the Star Wars book about crossing the chasm? You know, the –

    Shimel: Yeah. Sure do.

    England: – DevOps has gone from the early adopters to mainstream now. It’s definitely –

    Shimel: Oh, it’s certainly mainstream, but I –

    England: – the majority.

    Shimel: So I think it’s in the early majority, though, not the later majority.

    England: That’s true. That’s true. It’s still not everyone; it’s still not—but, yeah, but it’s certainly jumped—it’s certainly bridged the chasm and it’s on its way up that curve.

    Shimel: Oh, no doubt about that. No doubt about it and, hey, we live it every day here at devopsy.kinsta.cloud, as we continue to kind of chronicle all this. Anyway, Rob, we’re about out of time. I wanna thank you for joining us all the way from New Zealand. Look forward to seeing you in London and your presentation and thanks for doing everything you do, Rob. I mean, you know, you’re a healthy IT skeptic. In IT, skepticism is healthy, right?

    England: It sure is and I love doing it. Thanks, Alan. It’s always a pleasure to talk to you, my friend.

    Shimel: All right, Rob. You be well. We’ll see you in just a couple—well, it’s about two months now, probably.

    England: See you there.

    Shimel: All right. Rob England, IT Skeptic, speaker at DOES London on June 5th and 6th at QE Conference Center. This is Alan Shimel for DevOps Chat. We’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • DevOps Chat: BlueOcean Puts CD Pipelines Within Reach of Every Team

    DevOps Chat: BlueOcean Puts CD Pipelines Within Reach of Every Team

    Blue Ocean brings easy-to-use continuous delivery for teams to everyone. Years in the making, Blue Ocean is a major project built from the ground up for Jenkins Pipeline. I had a chance to speak with two of the key contributors from CloudBees and the Jenkins community, James Dumay and R. Tyler Croy. Tyler is on the Governance Board for Jenkins.

    Blue Ocean provides:

    • Sophisticated visualizations of CD pipelines, allowing for fast and intuitive comprehension of pipeline’s status.
    • Pipeline editor makes creation of pipelines approachable by guiding the user through an intuitive and visual process to create a pipeline.
    • Personalization to suit the role-based needs of each member of the team.
    • Pinpoint precision when intervention is needed and/or issues arise. Blue Ocean shows where in the pipeline attention is needed, facilitating exception handling and increasing productivity.
    • Native integration for branch and pull requests enables maximum developer productivity when collaborating on code with others in GitHub and Bitbucket.

    As usual our conversation in the streaming media player is immediately below.

     Streaming Audio

    Transcript of our conversation

    Alan Shimel: Hey everyone. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud. Welcome to another DevOps Chat. We have two guests today on DevOps Chat. We have James Dumay and R. Tyler Croy of the Jenkins community. James, Tyler, welcome to DevOps Chat.

    James Dumay: Nice to be here, Alan.

    R. Tyler Croy: Thanks for having us.

    Shimel: Thank you. Let’s start off though with just a little background of each of you. James, you’re coming to us all the way from Australia. In deference to the distance, we’re going to let you go first. Why don’t you share with our audience a little bit of your background?

    Dumay: Yeah, sure thing. So I’ve been probably building development tools for the last 10 years. I think I’ve found my calling here. I love making developers more productive. I also want to make developers happier. So I do have this bee in my bonnet that developer tools are difficult when they’re boring and they’re not very pleasing. It’s my life’s mission to turn that around.

    Shimel: Excellent. Tyler, how about you?

    Croy: I’ve been with the Jenkins project a little over eight years now. I started using it when I was a back-end services engineer, a few startups ago. Every single company that I’ve joined needs more continuous delivery or some non-zero amount of continuous delivery stuff. So I found myself getting more and more ingrained in the Jenkins project and bringing Jenkins to bear in companies to ship products faster. Now I work at CloudBees talking about how you can do that and help other people see the light with some of the Jenkins stuff I’ve been doing for a while.

    Shimel: Tyler, I don’t want to embarrass you. You actually are—I don’t even know the word, but you’re one of the—on the steering committee or the governing committee for Jenkins. Is that the right way to put it?

    Croy: I guess you would say I’m on the Jenkins governance board. In the beginning of the Jenkins project, there was Kohsuke Kawaguchi who was the founder of the project, and then there are a few other core folks that were floating around that helped get Jenkins off the ground. Andrew Bayer who is a major contributor to the pipeline toolset, is one of those people. So I’ve just—Jenkins became a really important part of my life. I started spending a hell of a lot more time with Jenkins, and now I’m one of the people that makes sure that the project continues to move forward.

    Shimel: Excellent. James, I don’t know if you mentioned your role other—at this point, other than you’re cuckoo for Jenkins. What exactly is your role right now?

    Dumay: I’m director of Product Management at CloudBees, but I’m also a community leader for the Blue Ocean project. I do all the outreach and talk to all the users. It’s good fun, but previously before I was at CloudBees, I was at a small Australian startup called Canva. They do an online design tool. Prior to that, I spent seven years at Atlassian, where I was product manager for actually a competing product.

    Shimel: Absolutely. Well, we’re allowed to have competing products. They may not be any good. I’m only kidding. James, you mentioned the magic word. You get the first prize today. That was Blue Ocean. Today’s a bit of a—more than a bit—today is a big day in the Jenkins community. This release has been highly anticipated. It’s been in beta and in testing, alpha before that for some time. Talk to us. What about it? Why should people care?

    Dumay: All right. That’s a big question. So I guess we’re living in a really interesting time in the industry. We have this—there’s this ride of exponential change that is happening across our industry, whether it’s tooling and technology and process, or just the raw number of people writing computer software in the—we’ll be in the year 2020 soon. I think if you look back in the previous 10–20 years, the amount of companies out there that are writing software today and were not writing software 10 or 20 years ago. So Marc Andreessen speaks about software eating the world, where all the value that companies provide slowly but surely are being made, not by the engine in a Ford motor vehicle, but it’s the software on board the Ford motor vehicle.

    So it’s an interesting time to be a software developer, or to be in this field, but it’s also a really interesting time to be a tools creator. I think with this increase of people in the industry—it’s not like we have lowered the bar to what we call a software developer, but I think there’s a lot more people today who, in their jobs, whether it be financial services, or in other industries, who are finding their job involves writing software. I think there’s a big challenge here, and Blue Ocean is founded on going out there and solving this problem, that how do we make the millions of software developers or even people who are just writing software as part of their jobs, how do we make them more productive? How do we make sure they can get what they need to get done as quick as they can get it done at the highest quality that they can get it done with the best tools possible?

    So with Blue Ocean, we’re sort of focused in on the practice of DevOps and on continuous delivery. We set ourselves a goal. What if we can make it really easy for people to adopt continuous delivery? Blue Ocean is our answer to that.

    Shimel: Tyler, James—I think James made some important points. What can you add there? Why—let’s step back a second. Let’s say our audience is vaguely familiar with Jenkins. Most of them probably use it, but there’s some maybe that don’t. What is—let’s start with what is Jenkins to them? What does Blue Ocean represent to Jenkins?

    Croy: Sort of at a high level, Jenkins is an automation server. Jenkins is probably the most well-known tool of its kind across the entire software industry. As far as helping developers build and test and deploy their software, chances are with most organization today, if someone doesn’t think they’re running Jenkins, they might just not be aware, or they might be so far removed, or that it’s hiding, that they don’t know that it’s actually there. It’s pretty omnipresent in the industry right now.

    One of the big things about I would say the shift in the industry that has made Blue Ocean important—when I first started in northern California about 10 or— [inaudible] 10 years ago, continuous integration was this really big, important thing. I kept coming to companies who either didn’t have a continuous integration server, or didn’t practice—nobody but the developers knew that there was a continuous integration server. As the industry has shifted towards this more and more rapid pace of “Let’s practice continuous delivery. Let’s get product and value to our customers as soon as possible,” it’s no longer acceptable for just the developers to get feedback to what’s going on in that process.

    So I think the important thing for Blue Ocean, and I would say broader software industry, is that continuous delivery is not a developer thing. It’s an entire team thing. It’s an organizational thing. Blue Ocean is designed from the ground up to make sure that people who might not be writing code every single day, or they might be designers, or they might be product managers, or stakeholders of some form or fashion in the software development process. They need to know what’s going on and Blue Ocean is going to give them a window into what’s going on in the delivery pipeline. That’s a pretty dramatic shift from the Jenkins that was created 10 years ago, which was just for developers.

    Shimel: Got it. Got it. Now guys, I’ve had the—I don’t know if the word is a pleasure, but I’ve had the—well, it was a pleasure in a lot of ways, but I’ve had the experience of being involved with open-source projects in the past. It’s a fickle thing being part of a community. It’s even harder when you have a corporate entity such as CloudBees in this—CloudBees isn’t alone in this. There are many companies that are mentoring, managing—whatever you want to call it—open-source projects. Talk—I loved what I saw of how that relationship was handled as it applied to Blue Ocean.

    Guys, can you give us a little color on that? No pun intended with Blue Ocean and color, but a little background on how you worked with the community to deliver, I think, what the community consensus was what was needed.

    Dumay: Just to preface this. So this is my first time working full-time on behalf of the commercial entity for _____ community. So I—when we started at Blue Ocean, I kind of put myself in Tyler’s very capable hands. Tyler had had a lot of previous experience, not with Jenkins, but with other projects, walking that fine line between community and the need for the business sponsor, I guess. So it’s been an interesting process. I think certainly for CloudBees, a healthy Jenkins community is a healthy CloudBees, and a healthy CloudBees is a healthy Jenkins community. It all feeds into each other. As long as, I think, we take things from a project perspective, like what’s good for Jenkins, we’re making good decisions in both aspects.

    Certainly, we had been running—more in terms of Blue Ocean itself, we had been running for multiple years Jenkins community surveys, and one of the top issues people would have liked to see addressed in that feedback had been the user experience with Jenkins. They really wanted it to be easier to get started. They really wanted clarity when they’re looking for particular cases, information. I think there was a real groundswell there to see some improvements, and see some sort of more modern thinking around how to solve problems. I hope that we’ve done that. Certainly the feedback that we’ve been getting from the community has been pretty great.

    Just on the community itself, I think software developers can be a pretty passionate tribe of people. So it’s—the Jenkins project is no different from the wider developer community. They’ve been passionate in a very encouraging way, in a very forgiving way as well. Particularly when you go ahead and think about any product that has—web product that has been redesigned. So the people get very upset. They’re very invested in the tools that they use, or the products that they use, and then you move their cheese, and people go “Where did that thing go? Where did this other thing go? No. I was using that. Bring it back.” I think with the Jenkins community, I think they’ve been very—I think they’ve wanted the change for so long that as things change, we—they’re getting some new goodies in their bag and they’re happy to let some of the old bits disappear.

    Croy: I think there’s also—if you look at that feedback from the Jenkins user list going back years and years and years, there’s been—most people, I would say, that contribute to the Jenkins project, note they’re new, I guess past tense, because Blue Ocean is one meadow now—knew that something needed to get fixed, and someone needed to do something to really improve and set up Jenkins for the next 10 years. The skill set and the passion and the vision really wasn’t there.

    So when James and his team, his colleague Michael Neale and some of the other people, really started to get involved, I think it was easier for other contributors in the project to rally around that. It was clear that not only did they know what they were doing, but they understood the challenge in that we needed to think about the design from the ground up, as opposed to reskinning or reseaming Jenkins. They needed to evaluate it from a user experience standpoint and start from 2016 rather than 2006, which is when the project really started. So I think that was really helpful to have some—a passionate group of people with vision to drive it forward.

    Shimel: A passionate group of people with vision can accomplish a lot. That’s for sure. Guys, let me ask you—we’re almost out of time. What—for each of you, and we’ll go with James first. James, what do you think is the single biggest aspect or feature of Blue Ocean that our listeners should take a look at?

    Dumay: That’s very unfair, Alan. I love them all.

    Shimel: How can a parent decide? But guys, so pick one. Doesn’t have to be your favorite or biggest, but one that we’d like to call out.

    Dumay: The official pipeline editor. So _____ delivery pipeline is difficult at the best of times for people to create. So we set ourselves a challenge. What if we could make it very easy for people to create a continuous delivery pipeline using Blue Ocean UI. The one thing I really like about it is it really is for everyone. We talk a lot about—we’ve got a lot of plans for the Blue Ocean in the future. One thing we talk about is the Fisher Price’ing of the editor. I don’t know if you’re familiar with Duplo blocks you give a toddler. But you can get all these different attachments, all these crazy things, and you can customize your own creation using Duplo. It’s non-checkable Lego. So really, Duplo is for everybody. So anybody of any age can—of any skillset, can construct something from Duplo.

    The thing that I like about the—I guess the vision behind the editor is anybody can construct a continuous delivery pipeline, even if they don’t have coding knowledge. Maybe they want to take—they have—we can go as far as they can have a PHP website on a Dropbox folder and they want to upload that, deploy that continuously to their webhost, their DreamHost or something like that. That’s the kind of—we want to bring continuous delivery to everyone.

    I think the communal pipeline editor is the vehicle to do that. One of the great things about the editor as well is that it is what you see is what you get. So when you build it in the editor, that’s exactly how you visualize it later on in Blue Ocean, as that pipeline is executing. It’s really powerful in that way.

    Shimel: Great. Makes sense. Tyler, how about you?

    Croy: So my interactions with Jenkins are typically when something goes wrong. I think that’s maybe a bit more common for an infrastructure administer or developer. So, for me, I would say the No. 1 killer feature with Jenkins—with Blue Ocean and Jenkins is that the clicks to get from a failure or something going wrong to seeing what actually went wrong, it’s pretty much one click. So the visualization of status is so much faster and more immediate in Blue Ocean that when I come to Blue Ocean to figure out what test failed, or what went wrong in my pipeline, I get that in a matter of seconds, as opposed to drilling around and hunting through console help. So for me, that’s probably the killer feature.

    Shimel: Make sense. Guys, we’re going to wrap up here in a moment, but just quickly, for people who want to find out more about Blue Ocean, where can they go? James, Tyler?

    Dumay: No problem. They can go over to Jenkins.io/projects/blueocean or the Jenkins blog, which is Jenkins.io/blog.

    Shimel: Okay, Tyler, I’m going to hit you with the last question. Now that Blue Ocean is 1.0, what’s next?

    Croy: [laughter]

    Shimel: [laughter] You didn’t expect to get a rest, did you?

    Croy: No, no. I think the really important thing that’s next for the Jenkins project is I would say the next three months of Jenkins pipeline and Blue Ocean adoption. Now that we’ve got the tools that we’ve brought to the broader software industry for building and constructing and running continuous delivery pipelines, we’re going to need to iterate, on them and we’re going to need to make them better as more and more people start to adopt continuous delivery. I think we’re, certainly before the end of the year, we’re certainly going to find new things that we can add into Jenkins to make that an even more enjoyable experience.

    Shimel: Absolutely. Hey guys, congratulations. I know it’s easy on release day to say something came out. There was a lot of work here, an awful lot.

    Croy: Indeed.

    Dumay: Very much so. Thanks.

    Shimel: Thank you, James, Tyler, great job. R. Tyler Croy, James Dumay of CloudBees and Jenkins talking about Blue Ocean, the big news around Jenkins and CICD Pipelines. Guys, thanks very much. Hopefully we’ll have you back soon on another DevOps chat.

    Croy: Thanks a lot. See you later.

    Dumay: Thanks.

    Shimel: This is Alan Shimel with DevOps Chat. We’ll see everyone soon on another DevOps chat, but until then, have a great day.

    — Alan Shimel

  • DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet

    DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet

    The results and analysis of the State of DevOps Report 2017 report are due out in early June. just in time for the DevOps Enterprise Summit London June 5-6. In this DevOps Chat we speak with Puppet exec and one of our favorite interviews, Nigel Kersten.

    Of course, Nigel and the folks over at Puppet have been co-producing the State of DevOps report and survey for six years now. For this year, Nigel along with Dr. Nicole Forsgren and Jez Humble of DORA, will be co-presenting at the DOES London, where they will announce the results of this year’s survey. It should be quite interesting.

    Nigel gave us some sneak peeks and early trends for this years report, as well as discussed the DevOps Enterprise Summit and, as usual, some good info on what is happening at Puppet and the DevOps world in general.

    You know the drill by now: The streaming audio of our conversation is immediately below and the transcript of our conversation is below that. Enjoy!

    Streaming Audio

    Chat Transcript

    Alan Shimel: Hey, this Alan Shimel, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. And we’re happy to be joined again by a repeat guest on DevOps Chat, none other than Nigel Kersten of Puppet. Nigel, welcome.

    Nigel Kersten: Hey, Alan. Nice to talk to you again.

    Shimel: Good to speak with you. So, Nigel, we’re not talking about the latest and greatest from Puppet today. Well, maybe if you wanna just mention it quickly, feel free, but I wanted to really talk a little bit about the upcoming DOES London event, Gene Kim’s DevOps Enterprise Summit, which is June 5th and 6th in London at the QEII Center, and you will be presenting there. Correct?

    Kersten: I will be. Yep, with Dr. Nicole Forsgren, who’s one of the other authors of the DevOps report, and DevOps Enterprise Summit London last year, I think, was honestly one of the best events I’ve been to in this space for a long time and I adore London for lots of reasons, and so it’s always great to be back there.

    Shimel: Yeah. And, Nigel, correct me if I’m wrong – is Jez Humble also presenting with you and Dr. Nicole?

    Kersten: I think Jez probably will be, but I’m not sure if it’s quite confirmed yet. We’re sort of trying to work out how we’re covering all of the different events, for the various roadshows and webinars we’re doing around the DevOps Enterprise Summits and the DevOps enterprise report.

    Shimel: Yep. Okay, so I guess we’ll stand by for final confirmation on that, but, certainly, you and Dr. Nicole will be on, and, of course, Nicole has appeared on our show before and we’ve talked a little bit about not only this year’s DevOps survey but past years’ as well. But, Nigel, for some of our listeners who maybe weren’t lucky enough to hear previous talks about it, this is what? The sixth or seventh year of the State of DevOps survey?

    Kersten: This is the sixth year, which is kind of amazing ’cause, you know, I think, when we first started with the fantastic Alanna Brown, who also works here at Puppet, everyone was a bit skeptical about it. I think this was even before you’d started devopsy.kinsta.cloud and people were like, “Is this really a thing? Do we really need a survey about all of this?” but I think it’s just gone from strength to strength over the years. So, yes, I guess, for the people who are sort of new and may not have come across the report before, what we essentially do is we survey a whole bunch of practitioners—we’ve done tens of thousands of ’em around the world over the last six years—and what we do is we ask about the practices and the tools that they use, but also some metrics about “What’s your mean time before failures? How quickly can you deploy your software? What sort of practices do you use?” as well as what sort of outcomes you have. And then we do a statistical analysis on all of that so that we can—and we actually end up showing that there’s a huge gap between what we call “high-performing” IT organizations and everyone else.

    And, in fact, interestingly enough, over the last few years, we’ve shown that the gap is increasing over time, so the people who’ve adopted DevOps practices—because, essentially, what we’re showing is we’ve been able to show statistically that what we tend to call “DevOps practices,” around using CI, using CD, using infrastructure-as-code software, doing continuous deployment, using testing, storing things in version control, all of these practices, when you cluster them, are the people—the people who employ these practices are the people who have high-performing organizations. And they’re really huge statistics—they tend to be thousands of times better, being able to deploy just ridiculously faster—and, essentially, what this ends up showing is you really don’t have to sacrifice quality for speed or vice versa, so we’re seeing that these people are both producing high-quality infrastructure and applications and they’re doing it far more quickly than everyone else.

    I think one of the things I’m really proud of with the DevOps report is that it’s useful to sell DevOps practices within your organization, so I talk to an awful lot of customers and practitioners out there who are really thankful for the report because it tends to be focused on business outcomes. So, even though we’re surveying practitioners, it’s something that’s really applicable to C-levels and VPs and directors. They can look at this with them and go, “Ah, this is where the industry’s moving and these are the sort of benefits we’ll actually get.”

    Shimel: Excellent. And, Nigel, in typical humble Nigel self, you’re—I mean, let’s give a little bit more flavor, if we can. Over the five previous years, I think there’s over 25,000 responses to these surveys.

    Kersten: Yeah, no, that’s right. 25,000 over five, six years. It’s pretty crazy.

    Shimel: So that does represent a—in a field like DevOps, which is fairly new, right, it represents a sizable amount of people and organizations who have taken the time and contributed to the data that you guys have analyzed over the years. And another important thing, I think, to note for our audience is not only the analysis of the data but even the questions themselves are, from a statistics point of view, a statistician’s point of view, rigorous—rigorously designed and rigorously analyzed. And, look, having a Ph.D. statistician helping you with it doesn’t hurt, but so these are not just some –

    Kersten: No, it’s not your average –

    Shimel: – go up and doing surveys.

    Kersten: – sort of marketing survey at all, and I think this is why it’s always really important for us that—you know, we’re a software vendor and we’re in this space and there’s a lot of people in our space who do pretty fluffy kind of surveys that only take two or three minutes and then some sort of ridiculous claim gets made, so this is why we’ve always been really keen on working with the external parties of Gene Kim, Jez Humble, Dr. Nicole Forsgren. Particularly Nicole. She’s a trained statistician who’s literally got a Ph.D. and has spent her career working on studying organizational performance, which overlaps with DevOps in really interesting ways, but I think having that external rigor, and I think it helps keep us honest as a software vendor. So this is something we really loved, having a partnership with them, ’cause this is their specialty.

    They actually—to give them a little bit of a plug, they have their own organization, DORA, DevOps Research and Assessment, where they’ll come in and do benchmarking of your organization and actually measure how you’re actually doing, so I think it’s just really great. We’re clearly really plugged in as Puppet into this whole community, but they plugged in at a different level, and working together, I think, means that we both get to expand reach and bring a bunch of statistical rigor to something that could easily devolve into a self-serving survey, which ultimately doesn’t –

    Shimel: Hey, Nigel?

    Kersten: Yep?

    Shimel: I thought I lost you there for a second. I apologize. Agreed, I mean, on all of the above. And that’s really—I want people to understand that, that this isn’t a marketing survey they up and have done now for six years running. I wanted to make another point, Nigel, and that is, certainly, over the last two years at least, and I would imagine for this year as well, one of the real nuggets of wisdom that have come out of this analysis is really just how high-performing or what high-performing IT organizations mean to the bottom line of these companies that are doing it. I think, at some level, we all at a gut level say, “Well, if you’re performing better, you’re releasing faster, it should translate into a better company,” but, certainly, the State of DevOps report—survey and report is one of the few that are out there that really connects the dotted lines here.

    Kersten: Absolutely. So you look into the sort of things that people are actually sort of seeing. What we’re seeing, so to sort of hit some of the boon stats from last year, is that we’re seeing the high-performing IT orgs, three times lower change-failure rate, 200 times more frequent deployments, and 24 times faster recovery from failures. And those are really amazing stats because I think they really resonate, both with practitioners who’re the people who are getting woke up in the middle of the night or having to deal with the pain of a deployment that didn’t work properly, but they’re also the sort of stats that your average, been-away-from-the-technology-keyboard for a few years, high-level executive, can look at it and they go, “No, that’s actually what we want. We want to be able to deploy more frequently,” because, I think, one of the lessons that SAS has taught us is the reason a lot of SAS companies outstrip on-premise competitors is because, every time they deploy, it’s a chance for learning, it’s a change for feedback.

    And Agile has taught us, from traditional software development, the more frequently you can deploy, the smaller the deltas are in those deployments and you can do more frequent cost correction, so you can actually produce a much better outcome over time by deploying more frequently and being able to correct course more frequently.

    And, to, I think, bring it back to enterprise folks, not everyone always thinks about deployments in this way, but, every time you get a patch from your vendor, that’s another deployment. Every time you respond to a security incident internally, every time you have to follow through a recommendation of your audit and compliance committee—all of those things are deployments and the more pain-free and friction-free you can make the ability to deploy within an organization, the more responsive you’re gonna be to all the different stakeholders.

    Shimel: Yeah. Let me give you my favorite stat that you omitted or you just didn’t get a chance to, and that is these high-performing IT organizations have 50 percent less vulnerabilities post-deployment.

    Kersten: Yep.

    Shimel: That’s huge.

    Kersten: It’s a major. And you’re spending less time on that. And I think the other related one that’s really amazing is that the high-performers spend 22 percent less time on unplanned work and rework. And, for anyone’s who’s been neck-deep in infrastructure, it’s the unplanned work that kills you. It’s the context switching. You’re not making progress on your defined road map every time you’re having to spend time on unplanned work.

    Shimel: Yeah. So, Nigel, these are all fantastic insights and metrics, so now, of course, though, we’ll turn the table on you and say, “Hey, what have you got for us this year?” I know it’s early; I know you haven’t released the report yet. You’ll probably be announcing a lot of the results, I think, come out just at the time of DOES London, which, again, is June 5th and 6th, but is there anything you can share with our audience as maybe a preview?

    Kersten: So I think one of the things that I could share is we’re still going through doing the analysis, but we’re seeing that, again, the high-performing orgs are achieving just as well compared to everyone else, as they have in previous years. It doesn’t look like there’s only sort of peak, as far as implementing these practices. I think the whole industry, even people who have been doing this for a while, have still a fair way to improve.

    I think one of the really interesting things—well, there’s two big ones I wanna call out. One is that, this year, we spend a bit of time working on non-profit performance ’cause, in previous years, we’ve shown that commercial companies who are high-performing IT orgs tend to outperform their financial metrics, outperform in the stock market, their internal company goals, but, this year, we decided to focus on non-profit performance, and so we’re looking at things like, “What’s their operating efficiency like? Customer satisfaction? Quality of the products that have been shipped?” So we’re actually, I think, showing that DevOps practices in high-performing IT orgs impact in a positive way all sorts of industries, so I think that’s gonna be one of the really interesting sections.

    The other section, I think, that’s gonna be really fascinating is that we’re actually looking at what’s the—there’s a myth out there, to sort of back up a little bit, that DevOps practices tend to work if you’re building all of the software yourself, if you’ve got a web app, if you’re building a whole bunch of stuff in Node.js or something like that, and deploying it to the cloud, sure, you can do DevOps—you can do continuous integration; you can do continuous delivery—but, for those of us who are sitting there running commercial, off-the-shelf software, we can’t actually do that and we can’t actually obtain the benefits that are available by employing DevOps practices. So I think what we’re gonna be showing is that this isn’t true, that there’s a couple of things you can do as an organization, in the way you consume commercial, off-the-shelf software, to actually let you employ continuous integration, continuous delivery.

    Now the reality is you’re not gonna be able to test all the same kinds of things because, unfortunately, you know, lots of vendors that release software don’t necessarily have an API-first policy, so you’re not always gonna be able to test everything inside the application, like you can’t run unit tests, necessarily, ’cause it’s not your code, but there are a whole bunch of things you can do. And one of the big bits of guidance that we’re gonna be pushing is that, when it comes to commercial, off-the-shelf software, really try to make the installation as vanilla as possible. Don’t spend forever customizing it. And, if you’re having to customize it because that’s what your business processes say, in many ways, the lower-cost and better-outcome approach is to not customize the software and adjust your business processes because there’s something within your control, generally. And if you adjust those, then it becomes simpler to deploy that software into a CI system, to have Jenkins or Bamboo or whatever do deployments of it, do external black-box testing, make sure that it actually works, and then roll it out to production.

    So we’ve got a pretty strong belief that, when it comes to utility computing, to sort of use Martin Fowler’s distinction between utility and strategic computing.

    Shimel: Yep.

    Kersten: There are huge efficiency gains to be made there, but there’s a few things you can do to avoid those problems. The analogy I kind of come back to is that there was a period, I think, in the late ’90s and early 2000s, when lots of people would customize their Apache installs. They would sit there and come up with this fine-grained list of modules, configured in specific ways, and, every time they deployed a new version of Apache, they’d eke out another one or two percent performance by having this really customized installation. It turns out the actual cost to the business is really great because those tend to be manual processes—you’re turning yourself into a snowflake when you didn’t actually need to be—and I think the more you can commoditize the software you’re buying and that you’re building and that you’re deploying, the faster and more friction-free a lot of these processes are gonna be.

    Shimel: Got it. You know, Nigel, that—so I’m old. That’s firing up some old synapses in my brain back from the dot-com days, when I helped start a company called “Interliant.” We were an early ASP. And, mind you, this is before we have a modern cloud and virtualization and ubiquitous connectivity, but we were offering hosted Lotus Notes, PeopleSoft, Oracle applications, Lawson ERP—I don’t know if you remember Onyx was an early CRM tool back then.

    Kersten: Oh, yeah. Yep.

    Shimel: That’s a blast from the past, huh?

    Kersten: Totally.

    Shimel: Anyway, so our thought was to offer hosted versions of these applications. This is early, right? We called them “application service providers.” And what we quickly learned in—you know, when you go to market, and we did the whole IPO thing, all of that, but what we learned from our enterprise customers was that, as much as we wanted them to run a vanilla PeopleSoft or a vanilla Lawson or Onyx or even Lotus Notes, for that matter, the best we could hope for was about 80 to 85 percent of out-of-the-box, just plug-and-go. They always needed—and so what happened was we had to change our whole business model and we wound up acquiring a bunch of service bodyshops, for lack of a better word, who would come in and do that last-mile customization, if you will, that last 15 percent. And, as a result of that, I will tell you, the business model failed, ultimately bankrupt. And, if you look at all those early ASPs, none of them really succeeded—USinternetworking and Corio, some others—because we weren’t able to get people to use the vanilla configs that would have been easy for us to host, spin up, and put down.

    I think you see the same thing a lot today, with kind of bare-metal hosting. Right?

    Kersten: Yep.

    Shimel: Versus a traditional cloud virtual, you know, kind of hypervisor thing. How many people are using just vanilla bare-metal kind of config versus how many have—and you guys are Puppet, right? You’re dealing with this more than most, right? How many people are highly, highly customizing their bare-metals?

    Kersten: I think we’re seeing people shift away from customization. I think there’s probably a few things. One is I think people are realizing that a lot of this industry is sort of commoditizing, and so you may as well use off-the-shelf stuff. And so, if you’re just consuming stuff the way it was sort of shipped from the vendor, whether it be hardware or software, there’s sort of a general expectation that, I think, both software quality has improved—as much as we like to bitch and complain about software, I generally think software has gotten better than it used to be. There was no sort of Golden Age of incredibly rigorous enterprise software, as far as I’m concerned. I think stuff’s getting better. So I think there’s a couple of different pressures there, is that software’s gotten better, people have gotten more used to the idea that various things are being commoditized, and so they’re more willing to entertain the notion that the next layer up is getting commoditized.

    Shimel: Yep.

    Kersten: I think we’re also seeing things like—so here’s a good example, I think. If you consume Atlassian’s JIRA, the hosted version, versus the on-premise version, you can’t customize it as much. And, if you’re consuming GitHub the public service, versus GitHub enterprise, you can’t customize it as much. And so there’s a general understanding from people that, you know, an uncustomized version, or as much as is sort of possible, is actually pretty good and we don’t need to make everything completely different for everyone else because it means that documentation just works out of the box and people who’ve used the software somewhere else can join the company and have much faster on-ramp.

    And I think we’re seeing that—and this is a somewhat optimistic approach—that there’s a general desire for people to adopt software engineering principles and sort of DevOps cultural changes to get to that higher-performing IT organization state. And I genuinely think, if we keep pushing this sort of attitude out to people that, “If you don’t customize your software, adjust business processes to fit instead, that’s cheaper and you’ll get a better outcome,” I think all of those things combined sort of give me hope that we’re actually heading towards a world where people are giving up unnecessary customization.

    Shimel: I hope so. But, Nigel, we’re so far off our course here. You know, we were supposed to be talking about DOES London, and let me try to bring you back. So, I mean, obviously, all of this is background and the—this is why this survey is so important, so that we see these trends and we see it manifest itself in how companies are doing things and so forth. Let me ask a little bit—so, Nigel, you’ve presented at DOES before and I did an earlier interview today—I was talking to one of the program committee’s members for London, Jonathan from Hiscox—and –

    Kersten: Ah, yes.

    Shimel: Yep. And, forgive me, his last name—Jonathan Fletcher from Hiscox.

    Kersten: Yeah.

    Shimel: You know, and I’ve known Jonathan for some time—great guy. What we—you know, we forget—all rolled into one place in the space of two days, we’re gonna be jam-packed with all of this great information around DevOps and what we’re seeing and not only what we’re seeing but people are gonna talk about what they’re doing right now and what they did last year versus this year versus next year, what the findings are in our surveys, and I think that’s what really makes for a great event. Right? I think –

    Kersten: Yeah, I think there’s a couple of things that are really unique about it. I think one is that it’s not a vendor event, and I’m in the business of working the software company and we make and sell software, but it’s also really refreshing to go to an event where everyone who’s on stage is really there just telling case studies, their real-world stories. They’re not product-pitching to you. We’re not getting up and pitching Puppet Enterprise to you at all. We’re getting up and talking about the DevOps report, and everyone who’s there is—I think this is Gene’s big focus, is that everyone’s telling a real-world case study about what they’re actually doing, where the challenges were. It’s war. It’s honest. So I think that’s one section of it, that it’s real stories from out in the field.

    But, perhaps more importantly, it’s not just practitioners. And I think those of us who sort of have had a technical background can sometimes get too in the weeds about going and watching someone’s talk about this incredibly interesting deployment they’ve done and what they achieved, but we’re seeing business leaders talking about the actual impact on the business, how they ran large departments, large transformation projects. You know, the term “digital transformation”’s been kicking around for quite a long time, but we tend to see very sanitized case studies, driven either by a software vendor or a large consulting firm or the PR department of some multinational corporation talking about what they’re doing, and these tend to be really warts-and-all stories, going, “This is what we did and this is how it worked or this is how this didn’t work.”

    And I think some of those are some of the more fascinating stories, where people are getting up and talking about “Here were our lofty ambitions and we only got 60 percent of the way there and these were the problems we ran into.” And that, I think, is just really, really powerful, so I think the fact that you’ve got senior business leaders and executives there, as well as the fact that they’re all real-world case studies, is just a really, really powerful combination.

    Shimel: Yep. I agree with you. As a matter of fact, one of the things I’d love to see is more people get up and talk about failures, right, where maybe DevOps, they didn’t do it right, or what they could have done differently or what have you, where it didn’t work out right and this is what we did as a result, ’cause I think too many people come out of these events, out of Gene’s things, sometimes, and it’s like it’s all rainbows and unicorns and horses and such, and that’s great, but we—you know, as a dad, I try to teach this to my kids—you don’t always win. And that’s why you gotta learn to deal with failure and how to recover from that as well. And I think those are some of the best lessons for people to learn, is we learn more from our failures than from our successes sometimes, so.

    Kersten: Absolutely. And I think it’s hard because we haven’t always had a culture in the IT industry of actually performing postmortems and retrospectives on large projects that we’ve done, so it’s people don’t always have great answers for how they would have done things differently, but I think that’s something that’s actually also starting to shift quite considerably. We’re seeing DevOps has been a big part of that, of “Let’s do blameless postmortems,” and, hopefully, that continues so that we see more people being open about their failures.

    ‘Cause I think one of the things I find really frustrating—this has happened to me more than once and I don’t think this is gonna identify me, one customer or user, because they do so many of them—seeing your executives at Amazon summits get up and talk about how fantastic their whole cloud migration journey has been and that they’re all in the cloud and everything’s done and it’s absolutely wonderful. And then you go talk to the VPs or directors who are actually running those deployments and they’d be like, “Oh, God, no. We’ve only moved five percent of things and it’s been a miserable failure and we’ve now added three years to the project because we’ve fallen over organizational boundaries.” So I think that gap between the sort of PR-style business leader talk and the reality—that’s not a gap that actually exists at the DevOps Enterprise Summits, which I think’s been really fantastic.

    Shimel: Yep. Agreed. Agreed. Well, Nigel, our little 15-minute chat has turned into a solid half-hour, and I think we’re gonna need to call a break here. We are looking forward to the release of this year’s analysis of the survey, looking forward to your presentation along with Dr. Nicole at Gene Kim’s DevOps Enterprise Summit in London, June 5th and 6th, and just always looking forward to what you’re up to and what the folks in Puppet are up to. Many people, you know, when they think DevOps, they think of companies like Puppet, right? A leader in—I don’t know if they’re ever gonna do a DevOps Magic Quadrant, but—or some sort of stuff like that, right? But, I mean, seriously, Puppet’s one of the cornerstones here and you’re one of the cornerstones in Puppet, so it’s always great to hear what’s happening from you and getting caught up. It’s a pleasure.

    Kersten: Aw, thanks, Alan. So I will get one little pitch in, which is, because of DevOps Enterprise Summit being in London that week, we’re going to be announcing pretty soon that we’ve got a Puppet Camp happening pretty soon afterwards, so there’ll be a Puppet Camp in London, and this will be a slightly different tweak on the Puppet Camp format. We’ve run hundreds and hundreds of these events over the last few years, but we’re doing a slightly different thing, where we’re having a sort of more executive-manager-focused morning and a more practitioner-focused afternoon. So, if you’re someone who’s an IT architect, you might find mornings and afternoons both applicable, but we’re really looking to try and join together the conversation for sort of senior executive leaders as well as practitioners on the ground. So we’re already collecting a whole bunch of really great talks, both for the morning and for the afternoon, but, for those of you who are into Puppet, look out for a Puppet Camp London coming soon after DevOps Enterprise Summit.

    Shimel: All right. We’ll try to get info on that up on devopsy.kinsta.cloud for anyone interested. Nigel, fantastic, man. Thank you so much for the time today. We appreciate it. Nigel Kersten of Puppet here on DevOps Chat. This is Alan Shimel for DevOps Chat. Hopefully, we’ll see you soon at the next—on the next DevOps Chat. Until then, have a great day.

    — Alan Shimel