Category: Podcasts

  • DevOps Chat: Jenkins World Preview with Cloudbees CEO, Sacha Labourey

    DevOps Chat: Jenkins World Preview with Cloudbees CEO, Sacha Labourey

    Jenkins World, at the end of the month, promises to be the biggest and best yet. There could be upwards of 2,000 people at this year’s event. With a schedule full of training, sessions, keynotes and more, it is a don’t-miss event if you are into Jenkins, DevOps, CD and more. We sat down with Cloudbees CEO Sacha Labourey to discuss a Jenkins World preview.

    Sacha has guided Cloudbees on its journey in working with the Jenkins community while making the value of the Cloudbees offerings readily apparent. His past experience with JBoss has helped much. There is a Q&A with Sacha that we did as well, which has a lot more information.

    As usual, the streaming audio of our conversation is below, followed by the transcript of our conversation. Have a read or listen and hope to see you at Jenkins World!

    Audio

    Transcript

    Alan Shimel: Hey, everyone, Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat, and today’s DevOps Chat is all Jenkins World all the time. I’m joined by none other than Sacha Labourey, Labourey – I messed it up, but we’ll let Sacha pronounce it correctly. I only know Sacha about three or four years now and still can’t pronounce his name correctly, but, more importantly, Sacha is the CEO and visionary behind CloudBees. Sacha, welcome to DevOps Chat.

    Sacha Labourey: Thanks a lot, Alan, and my last name is a disaster to say for English-speaking person, so it’s “Labourey” – think about “Labor Day” and remove the “D,” but even that is hard to compute fast, so you did well.

    Shimel: Okay. Labourey. So, Sacha, we’re gonna talk about Jenkins World, and, for those of our listeners who aren’t aware, Jenkins World 2017 is coming to San Francisco. It’ll be at the Marriott Marquis Hotel there, right in downtown. And the conference runs from August 28th through August 31st. There’s so much planned this year, but, Sacha, this is – what? – the third or four, maybe more, Jenkins World that you’ve done?

    Labourey: Yeah, actually, I was looking at some of the numbers. I remember the first edition, probably – I’m not even sure if it was called “Jenkins World” back then, but, in 2012, we had 200 persons attending and we’re extremely proud of this, obviously. If you remember, the Jenkins Project was relatively new – it had just changed names in 2011 – so 2012 was 200 people. And, this year, we’re expecting at least 10X that number, so it’s gonna be a massive event in San Francisco.

    Shimel: Yep. And for our math-challenged friend out there, 10X of 200 is 2,000. And –

    Labourey: I think so, yes.

    Shimel: Yep. And, even comparing last year, Sacha, to this year, I think – I mean, last year was the biggest year ever done and I wanna say it was around 1,300, 1,400, something like that.

    Labourey: Yeah, absolutely. So it’s a big jump. You know, it’s almost 50 percent more than last year, so it’s a big step forward.

    Shimel: Good and congratulations on that. I think it’s testament, though, Sacha, to both the popularity and usage of Jenkins, as well as CloudBees. Right? And, you know, it –

    Labourey: Yeah –

    Shimel: Yep. Go ahead.

    Labourey: Yeah, you’re right. I think it’s like the perfect wind condition, you know? It’s, on one hand, you have DevOps maturing and being on everybody’s to-do lists, and so a lot of people wanna know more, wanna learn, want to share their experience. Jenkins is doing extremely well, as a project. Lot of new features in the last few years, you know, starting with Pipeline, Blue Ocean, and so on, so that makes it a very hot topic.

    And I think CloudBees, as you said, we’re doing extremely well as a company and we’re obviously extremely active in that field. We’re working a lot with the Jenkins community – I know you wanna talk about that, at some point – and so, yeah, I think it’s all of those different winds coming together and making that amazing conference.

    And, you know, we talk a lot about the numbers, right? Obviously, 2,000 people or above – it’s gonna be an amazing conference – but it’s also the quality of the content, the number of tracks and so on. This year is really gonna be a step up from last year, which was already an amazing conference.

    Shimel: Yep. Let’s talk about speakers and stuff for a second, if we can, Sacha. Obviously, you’re there and you will be doing one of the keynotes – I guess it’s the first day of the conference, right? The 30th?

    Labourey: Yeah, I’m gonna – yes. I’m gonna be one of the keynote, yes.

    Shimel: And, without letting the cat out of the bag and making new news here, can you give our audience maybe just a little bit of an idea of what to expect or what topics, areas you wanna cover, as part of your –

    Labourey: Yeah, absolutely.

    Shimel: – talk?

    Labourey: Yeah, the good news is, first, I’m not gonna be singing or dancing or anything like that, so you should be safe. And from a –

    Labourey: – from a content – [chuckles]

    Shimel: Uh-huh?

    Labourey: – from a content standpoint, obviously, like I try to do every year, we’re gonna be doing kind of a “state of the union” on what happened and where things stand, what we’ve learned, what works, what doesn’t work maybe, and show so a vision for the future. And the vision needs to be multiple years ahead, but it also need to be actionable, practical, and so we’re gonna be talking about some of the new things we’re gonna be announcing at Jenkins World, some amazing features. It’s gonna be great timing when you look at the maturity of DevOps itself. The type of requirements and needs from DevOps people also evolved with the other whole maturity of the space, and so I think we’re gonna have some pretty significant announcements that week that will fly very, very well with the community there.

    Shimel: Great. And then, in addition to yourself, Sacha, of course, Kohsuke – you know, KK – will be speaking and I’m sure everyone in the Jenkins and CloudBees community will be looking forward to that. He’s kind of revered within the community there, right? So…

    Labourey: Yeah. Every year, KK – so Kohsuke is doing his keynote and so he’s – I’m taking more of the business angle and the impact on the businesses; KK is obviously taking the community angle and the evolution of the project. And, when you look at KK, you see – you know, you perceive somebody who is not shy but pretty reserved, as a person, but I can tell you, when he’s on stage every year, it’s such a pleasure to see him there and make his status of the union, go through the numbers, and he’s a lot of fun. He’s really, really fun on those keynotes, so I’m really excited about this one.

    Shimel: Yeah. I mean, I’ve had the pleasure of watching KK present at a lot of the Jenkins Days and CD Summit roadshows that we did, over the last couple years. And I will tell you, you know, I think he kinda feeds off the members of the community and they, in turn, kinda feed off of him, so it is a great thing. I wanted to just also briefly mention another keynote speaker that you guys will be featuring at Jenkins World, and that’s my friend Jez Humble.

    Labourey: Yes, absolutely. Jez accepted to come and talk as a keynote speaker. Very excited as well. He makes great presentations. He has unique insights into this market, this transition, so I’m extremely excited about Jez Humble’s presence here.

    Shimel: Yeah. And, of course, Jez – I mean, Jez literally wrote the book Continuous Delivery, as well as the Lean Enterprise, and Jez is also a cofounder and, I think, working full time now with DORA, DevOps Research and Analysis, along with Gene Kim and Dr. Nicole Forsgren. So he had some great insight. You know, they surveyed something – I think it was 25,000 or 27,000 people over the last – or organizations over the last 4 or 5 years, and it really – I mean, again, great, great presentation.

    Sacha, if we can, while we’re on topic, you brought it up earlier or mentioned it, but I wanna really kinda bring it home for our audience, and that is that, yes, this is Jenkins World. It’s about Jenkins. Jenkins is an open-source project that, literally, millions of people are involved in, in one way or another. And CloudBees is intrinsically linked to Jenkins, right? But the relationship between CloudBees and Jenkins, Sacha, how do you explain it to our audience?

    Labourey: Yeah, you’re right. It’s a very important topic and I think we feed the community, the community feeds us. I think there is a very healthy relationship there. First, I think every company-slash-open-source-project behaves in a slightly different fashion. You know, I used to be at JBoss, at Red Hat, so we had already, in two companies, very different ways to interact with open-source communities and build a business on top.

    At CloudBees, I would say, we have yet another way to do that, and it’s really this church-and-state separation and the community’s the community. We obviously have an impact on the community because we’re pretty massive contributors to the project, but they are independent. They have their board; we provide requests that get approved or sometimes denied. So I think it’s very healthy to have this independent community and you can see it through the massive community beyond the Jenkins core itself, right? We’re talking about more than 1,400 different plug-ins, and each of those plug-ins are kind of like mini-communities around the project, so it’s a pretty massive ecosystem out there.

    And so, obviously, as a company, we leverage these install days and the power of this install days and help enterprises adopt Jenkins at scale and get insight into their installation and so on. But the community’s also benefiting a lot from, I think, CloudBees’ involvement. We’ve been massive contributors and initiators of projects like Pipeline; like Blue Ocean, the new user interface. If you look at some of the security issues that have emerged in Jenkins, much like in lots of Java programs out there, CloudBees has stepped up and spent – top quality engineers that have spent their weekends and weeks fixing a number of those. And that’s for the good of the community; that’s for the good of everybody. And, if CloudBees was not to do that, well, I’m not sure who else would be doing it, so I think, yes, there is a very healthy sharing taking place here, and I’m very proud we’ve been able to put that in place.

    Shimel: Excellent. Sacha, let’s turn a little bit – I said earlier on that the Jenkins World is August 28th through August 31st. The sessions, the keynotes, the exhibits – those are August 30 through 31st, but trainings and workshops actually start August 28th. And I wanna say the 30, 31st is a Wednesday, Thursday, and I believe the 28th is Monday, Tuesday.

    Labourey: Correct.

    Shimel: And there’s a whole lineup of training – some of it’s sold out already, but there’s a whole schedule of, I think, Jenkins training, Jenkins certification, and not just one curriculum of the same class being repeated. There’s a deep bench of different Jenkins training sessions and workshops available, correct?

    Labourey: Yeah. And, last year, that was already a huge success, so, this year, we’ve made sure that we have even more training course available, even more seats, but that’s a big, big one. And think about it. Obviously, for people who live in San Francisco and the Bay Area, it’s a relatively easy one to attend Jenkins World – it’s almost like a no-brainer – but we actually have a pretty important number of people traveling from the US but also from APAC or from Europe, and, for those people, it’s very important to make sure that they, quote unquote, don’t “just” attend the conference, and, way this layout are just laid out, you have a way to get trained, to get ready to be certified, which is great for your career. You get to attend workshops. So it’s very hands-on. You really come back and learn, have something you can factually show on your resume to your boss and explain that you’re really, you know, one, two steps above from where you were the week before, so it’s a great combination to come the weekend before, spend a few days doing training and workshops, and then attend the conference, meet with people, share expertise and so on, so it’s an amazing pack, I think.

    Shimel: Yeah. No, it’s a great opportunity. I mean, I should also mention that the DevOs Institute, partnering with CloudBees, will be offering some certification classes on the 28th and 29th at Jenkins World as well. I think they’ re gonna be offering the continuous testing engineer class, taught by Mark Cornbee, who wrote the curriculum, and I think they might be debuting “DevOps Leader,” which is aimed for people who wanna lead the transformation, and that’s a great class as well. I’m not 100 percent sure. If you go to Jenkins World, to the website on CloudBees, the Jenkins World section, you could see the DevOps Institute classes, as well as all – and, as I said, there’s as deep bench of CloudBees and Jenkins training available the 28th and 29th, and there are some workshops as well, I believe, on the 30 and 31st, for maybe people who just can’t get there all four days.

    Sacha, I wanted to talk about some of the other sessions that are gonna be on for the 30 and 31st. One, you know, shameless, I’ll promote – I’m actually moderating a DevSecOps panel on the 31st. I believe it’s at 10:30 in the morning. And that one will feature Rob Stroud of Forrester – I think Rob’s gonna be on a number of panels and sessions at Jenkins World. I’ll also have several of my friends from the security community, including Pete Chestna of Veracode, Andrew Storms of New Context. I think Andrew Wallgren, CTO of Electric Cloud, will be joining us. Derek Weeks or Curtis Yanko of Sonatype, and Pathik Patel, I believe, also. So that’s gonna be a great panel, but, Sacha, what panel or session would you – you know, give us three sessions, if you will, that maybe you’d like to recommend to our listeners.

    Labourey: Well, so there’s gonna be some special tracks on finance, for example, and I think those will be very well-received. We see a big interest from specific verticals, interested in sharing expertise, right? So, you know, I was just looking before, you have the Federal Reserve Bank of New York was gonna talk about their path to DevOps, so those are pretty amazing presentation, I think. DevOpsSec – obviously, there’s gonna be your presentation, but there is more to it. DevOpsSec is – I’m not gonna be arguing with you on this – it’s a very hot topic, so quite a bit around DevOpsSec coming up. That’s very interesting. And I think, also, a lot around testing. A lot of companies are interested now in automating testing – that’s still the part that adds the most friction to their delivery pipeline – and so you’re gonna see a lot of great presentations around testing there.

    Shimel: Great. Looking forward to that. Sacha, we’re almost out of time, unfortunately – it goes really quickly – but I just wanted to make sure we hit everything. People can still register for Jenkins World, right, if you go to cloudbees.com/jenkinsworld, home –

    Labourey: Absolutely. Yes, yes. The time is now. And it’s the right time, if you’re traveling, to think about it. You have to book your hotel; you have to book your plane. So don’t wait until the last minute to do it. Absolutely. Now is the time.

    Shimel: Yep. One other thing I wanted to quickly mention, something I’m really looking forward to, is, like last year, devopsy.kinsta.cloud will have a video broadcast booth set up on the show floor – we’re gonna be upgrading it a bit this year – but, on the second day, we’re actually gonna do a CEO panel, and, Sacha, you’re kind enough to join us, and we will have Rob Stroud again from Forrester there, as well as a few other CEOs. And we’re gonna do a wrap-up, really, of Jenkins World and the state of DevOps and CD and CI and where we are in the market, from a CEO’s perspective, so, for listeners, you know, that’s something – it should be up within a few days after Jenkins World. I highly recommend you listen in on that to get that CEO perspective.

    Labourey: Yeah, we’re gonna have some big names there, so it’s very exciting.

    Shimel: Yep. Should be fun. Sacha, before we wrap up, anything we left out about Jenkins World or anything else our listeners should be aware of?

    Labourey: Well, if you’re into DevOps, you can’t miss that event. That’s the only thing I wanna say. Just think about the amount of training, of workshops, the number of valid tracks you can attend. If you’re really serious about DevOps, it’s part of your job. Really, this is gonna be the conference you need to attend, so now is the time. Let’s go.

    Shimel: Okay. And, listeners, if you go through devopsy.kinsta.cloud, use the code “jwdevopscust,” so that’s J-W-D-E-V-O-P-S-C-U-S-T. I’ll put it in the show notes of the thing and maybe that’ll help, but, if you do, you’ll get a 20-percent discount, and everyone can use a 20-percent discount, that’s for sure.

    Labourey: [Chuckles]

    Shimel: Anyway, hey, we’re gonna call it wrap on this episode of DevOps Chat. Sacha, thank you so much for taking time out your – I know it’s later in your day over in Europe, and we will see you in San Francisco in just a few weeks.

    Labourey: All right. See you there, Alan. Thanks a lot.

    Shimel: Okay. Sacha Labourey, CEO, CloudBees, talking to us about Jenkins World. I’m Alan Shimel for devopsy.kinsta.cloud, DevOps Chat. Thanks, everyone, and we’ll see you soon on the next DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Rundeck, Putting the Ops in DevOps, with Damon Edwards

    DevOps Chat: Rundeck, Putting the Ops in DevOps, with Damon Edwards

    In this DevOps Chat we speak with Damon Edwards, co-founder and chief product officer of Rundeck. What I like to say about them is, Rundeck putting the Ops in DevOps. But Damon needs no introduction to those who have any familiarity with DevOps. He is one of the early leaders of the DevOps community and continues to evangelize DevOps around the world. In fact, he is speaking at our DevSecOps event at RSA APJ in Singapore July 25, which you can find here.

    It has always been a hope of me personally to have Damon as a guest on DevOps Chat. Besides being a great interview, Damon and Rundeck are a great story of an open-source project growing organically, spawning a great commercial business. This is harder than you think and Damon tells us a bit about it in this interview.

    As usual, the streaming audio is immediately below and the transcript is below that. Enjoy!

    Audio

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel, editor in chief of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. We’ve got a really, really special guest for this DevOps Chat, it’s one of my heroes in the DevOps movement from when I first started researching what DevOps was and it’s about. I’m thrilled to have him appear on our DevOps Chat today, none other than Damon Edwards. Damon, welcome.

    Damon Edwards: Thank you, Alan. Thank you for having me and thank you for those kind words, I’m excited to be here.

    Shimel: Thank you. So Damon, I’m going to guess a lot of people in our audience have heard of Damon Edwards, instrumental in putting together DevOps Days, especially DevOps Days at Silicon Valley kind of drove that for a number of years. You had several different companies, both open sources and consulting, and probably maybe even more than all that, Damon, you have appeared—I don’t even know if you keep count any more—at how many different DevOps Days events or other DevOps related events where you’ve spoken at. I mean, do you know? Have you kept track?

    Edwards: I don’t know, [Laughs]. I know it’s less than John Willis, because he reminds me of that on our podcast, but DevOps Café, I’m going to give a cross plug for that. We just had you on, Alan, as a guest, and you were fantastic. Yeah, I kind of lucked into just sort of right place/right time. We were really interested in how do you move fast—we called it Dev2Ops ourselves internally, our consulting business we used to call DTO Solutions that we have. And it was really all about how do you help organizations move faster? For a long time, scale was the problem. Hey, how do you deploy, hook into a thousand servers, right? A thousand servers used to be a big deal. And then it suddenly came to be that, hey, we can deploy anything to anything, that’s not really—deployment scale is not really the problem, speed is the problem. That organizations can’t move fast enough, that the pipeline is jammed, that the organization is kind of stuck in cement. And the organizations that are able to free themselves and decouple themselves and move in this new and fast way had a strategic advantage, were really kicking the butts of the big traditional companies that were kind of locked in place.

    So we really started asking ourselves, why is that? Our customers started asking us, why is that? And that really got us into lean and all those things. And at the same time, John Allspaw gave his big talk at Velocity, I saw that, you know, fell in with John Willis and Thatcher Dubois and the rest of the crowd and the DevOps movement was born. And we kind of became known as the folks who are great at taking the design patterns that you see on stage at the big high flyers and translating them to the big enterprises out there. So that was DTO Solutions.

    Then along the way we had a side project called Rundeck that was an open source tool, I’ll get to that in a second, but it really just took off. And after awhile, enough people called us about Rundeck, we really got excited about it, and there are two reasons why we decided to jump with both feet into Rundeck. The first being that I feel like operations is a DevOps frontier that’s not truly explored yet. I think in a lot of big organizations the dev side, they’ve got dev talking better to QA, they’ve got the build pipeline going, the little dev test cycles are going a lot faster. Maybe deployment’s happening a lot faster. But these DevOps principles haven’t really entered into full operations mode yet. A lot of big operations organizations just haven’t been able to transform themselves, and we saw DevOps, especially we saw Rundeck as a tool being used just to do that. So as a way to, number one, I think we were always product guys at heart, we wanted to see where we could take it. But number two, I really feel it’s helping push the DevOps movement to a new place.

    Shimel: Yeah, I agree with you. And Damon, just again, adding a little color, you actually have a video up somewhere, it’s kind of a brief history of DevOps. For any of our listeners who really want to know kind of how DevOps got started, Damon has a great video on that that I’d highly recommend. But let’s jump into Rundeck. Damon, as you mentioned, it was a side project to what you were doing with DTO. It was open source, wasn’t it?

    Edwards: Yeah, Rundeck’s core is it’s an open source product, an open source community. I Think last time we did some sort of estimate. There’s around like 25,000 different open source users out there. So it kind of became this silent—for us, we woke up one day and said, wow, a lot of people are really using Rundeck, and they were calling us saying, “Hey, we really want to do more with Rundeck,” and that led to the formation of what’s now Rundeck Inc.

    And if you want to talk about what Rundeck actually is, fundamentally, from a technology perspective, it’s an orchestration and scheduling platform. Right now a lot of orchestration happens within different silos, so there’s container orchestration, there’s configuration management orchestration, all kinds of different things like that. There’s enterprise job schedulers. But we noticed that as folks are transforming their operations organizations there was this layer that needs to span all of those different silos of tools, all the different islands of automation that they have, all the different systems that they have. They want to create procedures, operational procedures that span all of those different silos. And they want a place where they can define those procedures using whatever scripting language that they want. They want to be able to define the work flow, they want to be able to set security around it, that’s huge, because what a lot of people are doing in those procedures is not just helping their operations teams be more efficient and effective but they’re starting to open up more of a self-service model. Self-service operations is the big design pattern that I think is really driving us forward.

    Which is, all these people that need to do operational things throughout my organization, and as I start to transform my organization, how do I safely let them do things that could be deployment but it’s often remediation activity, diagnosing things, just doing operational things that I need to do, how do I let an ops team define those and be in charge of those and say who can do what, when and where, but allow other people to participate? And by participate, I mean two things. One is give them the button or the API to hit themselves to do the operational things that they need to get done, but also give them a mechanism to which those different teams, often in different business units, can define those operational procedures for the things they’re creating themselves, then have a standard mechanism to hand it off to operations where ops and security can vet them and then that ops and security vetting process can then turn around and give access to those other teams. So it’s like how do we let the operations decouple, let more people participate in operations, and do it all in a safe, sane and secure and audited and logged way? That’s where Rundeck shines.

    Shimel: Got it. I mean, Damon, you opened a bunch of different things in here I want you to kind of flesh out a bit. So number one is this whole idea of ops, right? My personal opinion is for too long with DevOps there was a very developer-centric focus of DevOps, and really, at the end of the day, ops is where it’s at for a lot of different reasons, especially in the world we’re living in. And you’re clearly working in there. But we’re not looking to recreate silos, right? There’s a place for the development team, right? They interact within Rundeck, if you will, with the ops folks, right? This isn’t for ops only kind of thing.

    Edwards: Right, right. If you look at organizations today, again it kind of goes back to our statement before about how scale is no longer the problem but organizational speed was the problem that caused the DevOps movement. And if you look at what’s going on with operations it’s a very similar thing. It’s not scale of the infrastructure as much as it’s complexity and scale of the organization that causes the problems. So in a lot of large enterprises, most every large enterprise, you have this central place called operations. Just kind of put the teams out of the way at this point, just think about the action of running all these things. You have all these different streams of activity that come into this central place, and that has to all hang together to form this enterprise. That is operations. That is the business. That’s where all the money is made. All these streams of development activity that come into that, essentially they’re part suppliers, so the next version, the next cogs in the machine that has to run, but it all has to hang together or we aren’t making any money, unless you actually sell software, which very few companies do these days, your running the service is the business. So operations is very important. But in that same vein, that operations, because things are so tightly coupled and it all falls to this one often central team, that becomes a huge bottleneck and a big problem, and it really ends up stunting or blocking the DevOps. That decoupling transformation that these organizations want to go to, they get blocked by the sort of calcification of the classic operations domain.

    And so we see these high flying organizations, what they’re doing now, the high performers, what they’re doing is a frame of how to uncap and decouple all of that operational activity. And in doing so, they’ve kind of realized there are three key pieces to what you’re working with. There’s the ability to—who defines the procedures? Who defines the procedures for the things that they’re going to be running. The second is, who can push the button for those procedures, button meaning through a GUI or through an API. And then third, who has the secondary or the operational, the management control of that action?

    Traditionally that all kind of fell to one group or one team and they’re grossly outnumbered by the rest of the organization and that became the big ops bottleneck. Their whole mindset was all about let’s protect ourselves from being overrun. Let’s protect ourselves because people are pushing things at us that they don’t really know how it’s all going to hang together, they don’t have that responsibility for defining things. So ops was in a very, very tough position and doing their best. We see these organizations doing a bit of a Tom Sawyer paint my fence or a jujitsu move by saying, hey, let’s redefine who does what where. Let’s allow that definition. Let’s allow those teams. They created these things, let’s allow them to participate in the definition of these operational procedures. And then let’s also, once it comes back to us, let’s let them push that button as well—for some things, not everything—maybe just certain non-destructive things, or maybe certain teams can deploy but certain teams we don’t want to deploy because it’s a different type of system or different security requirement. And you can move those things around and ultimately you can keep that third piece, the management and the compliance and the audit security control, with that traditional operations organization, or traditional operations skillset or management skillset who wants to control those things.

    So in this self-service design pattern it’s about dividing those three things up—the definition of the automation, the execution of the automation, and the management security compliance control over it—and allowing those to be moved to the parts of the organization where it makes the most sense for the flow of the business, speed, taking advantage of the labor that you have. It’s that mindset that these operations organizations are using to transform their organizations. When we saw that happening we were like, wow, that’s something really cool, and we jumped in with Rundeck Inc. with both feet.

    Shimel: Absolutely. Let’s talk a little bit about Rundeck Inc. as you called it. So Damon, was it about nine months, maybe more, maybe a year ago now, you and your—I’m drawing a blank, I apologize –

    Edwards: Alex Honor.

    Shimel: Right, Alex Honor, you and Alex have been doing Rundeck for as long as I know you. But about nine months or a year ago you brought in sort of a professional CEO, someone who I’ve known for years, a tremendous person based out in the Valley, Stephanie Fohn, as your CEO. And it really went from being Rundeck’s a side project of DTO Solutions, to Rundeck Inc.

    Edwards: Yeah, we jumped in full feet. We luckily landed Stephanie, it was a big coup for us. I think she described our situation “an embarrassment of riches,” and I wasn’t sure if she was emphasizing on the embarrass or the riches part. We started what’s now Rundeck Inc. as kind of an experiment to see, hey, what’s going to happen? It was Alex, myself, Greg Schuler, as lead developer of Rundeck. Alex is the founder of the Rundeck project. We had a small team going, we had some engineers scattered about, and things were working. But next thing we looked up and we had a whole bunch of large enterprises that were paying us for the early version of Rundeck Pro, which is sort of an enterprise enhanced version. There’s all kinds of features and extra plugins that really matter if you’re doing this stuff at scale. The open source is really defined for if you’re just a team and you need to define buttons and push buttons, then the open source is fully featured and there for you. Rundeck Pro is really about kind of adding things around and on top of it that the boss cares about, that big organizations care about.

    So we looked up and things were doing well. Stephanie came in and said, hey, we’ve really got something here and I want to be a part of it. So it was a big score for us. She is very well known on the security side of the house, a number of great successes there. She’s kind of found that operations and security is a very similar mindset, very similar set of people, and she’s really taken to it. Yeah, it’s been great, she’s brought in even more professional people.

    Shimel: It’s grown up to a company.

    Edwards: Yeah, we’ve got over 50 enterprise customers so far and we’re growing fast, so it’s a pretty cool, pretty fun ride.

    Shimel: Damon, your role now in Rundeck Inc., if we can call it that, is you are CTO and obviously cofounder, but CTO and evangelist, but your hands are still getting dirty talking to customers and helping.

    Edwards: Yeah, I’d say that’s mostly what I’m doing. Actually, Alex is the CTO, I’m the, I guess, Chief Product Officer, or head of product, these names that, you know, it’s a typical start-up, right? I focus a lot on the evangelism, a lot on the product side, a lot on helping customers figure out, A, well, figure out what they’re doing with Rundeck, and then also, B, help them figure out what they want out of Rundeck and driving that forward. So I’m still intimately involved with the DevOps community and out on the road doing that because I believe this is the next frontier, this is where you have to go. Straighten out your deployment pipeline and getting automated testing in there is a great thing, but if you’re any organization of any scale, this is the next major issue. You need to transfer operations otherwise you’re not really meeting the full DevOps vision. And the companies that are, have a distinct advantage over you.

    Shimel: You know, Damon, to me, DevOps is still very much like right out of the goal, where you solve one bottleneck only to find the next bottleneck. And that’s what we do is we keep knocking them down. And as you knock one down, another one further down the road shows itself. And I think that’s what we’re seeing in DevOps, is as we knock down bottlenecks in the CICD arena and configuration management arena, ops becomes where the next series of bottlenecks are, and that’s what obviously Rundeck is hitting in there.

    I wanted to talk a little bit, Damon, about a particular subset of this, and that’s DevSecOps. I think you almost inadvertently maybe backed in to the wonderful world of as we call it now cyber security or InfoSec or whatever you want to call it. Inherent in that ops mission is the idea of deploying securely and keeping a secure infrastructure up and securing your apps. And this is something that Rundeck is spending more and more time, more and more resources, more and more of the focus that I’ve seen anyway is involved around this DevSecOps mission. Comment on that?

    Edwards: Yeah, I’d say it’s sort of the intersection of security and operations. Really security, operations and governance. That if you think about what’s going on now—especially, well, two big trends. There’s the digital transformation trend, which is really just saying all of my systems need to be interconnected now for a consistent customer experience, that’s something the business wants. And then there’s all these new server lists, containers, the new API world where everything’s an API. So now we’ve got to define these procedures that span all of these different systems that used to be stand-alone stovepipes. And, everything’s turning into an API, so I’ve got to have a way to secure that, I’ve got to have a way to figure out who’s who and who can do what. So we kind of fell into that in terms of people use Rundeck as that tool, to say, hey, I’ve got my Chef automation over there, I’ve got some Kubernetes stuff over there, I’ve got some legacy stuff over there, I’ve just got a bunch of scripts I need to run over there, I’ve got these different Amazon services I need to hit, Akamai and these kinds of things. So they’ve got all these different things, buttons they need to push, and they each have their own logins, each of their own sort of way of managed security policies.

    So they look at Rundeck and say, hey, this is a place where we can enforce policy, or enforce this authentication and enforce the security controls. By defining these Rundeck jobs, it becomes a nice abstraction for that to say they can just call all this stuff, it’s real easy to string it together, and then I can define who can do what and where, and I’ve got the full access. In a lot of ways we call it like the key card and the camera. You can define who can do what through Rundeck, sort of the key card in your office building. But then there’s also a bunch of cameras, right? Not that we don’t trust you but we have to prove that you didn’t do anything bad with your keycard. So the kind of keycard and camera metaphor, we talk about that internally, but we should probably talk about that more externally. It’s something that we see a lot of people implementing with Rundeck in this new world. It’s a way to satisfy the security and governance demands but also do the new ops stuff.

    Shimel: Damon, we’re a little overtime already but I wanted to just quickly mention that you’re going to be appearing at RSA APJ, which is the largest info sec or cyber sec related show in the Asia Pacific region. We’re putting on a full—we meaning Sonatype, DevOps Connect and a few others—are putting on, Rundeck is a sponsor, is putting on a DevSecOps day there, and you and John Willis are headlining, and for any of our listeners who are in Singapore or around Singapore, that’s on July 25. And on July 26 I think we’re going to try to do a mega meetup group, several meetups, different meetup groups within Singapore. Also at RSA APJ, and you and John will be presenting there as well.

    Edwards: Yes, we will. You guys do a very good event. We’ve done the one here in San Francisco, excited to do the one in Singapore. Singapore is actually a great DevOps community out there with all the banking and finance and whatnot. It’s good work being done there. And the event’s great. It’s not just for security, it’s really looking at the end-to-end pipeline I’d say. It’s more like how do you bring these enterprise concerns into the DevOps story. And I don’t want people to think it’s just, hey, if I’m not in security, I don’t need to go to this. I think it’s really good for anybody who works in the enterprise and wants to think about the nuts and bolts of how do we get this stuff done so we can move fast and be secure or sure in what we do.

    Shimel: Absolutely. And you mentioned RSA, Damon, actually I’ll have some news about that hopefully within the next week—RSA San Francisco next year is April in San Francisco and I think we’ll be doing a DevSecOps day there as well. I think you presented, we’ve done three or four of these, I think you’ve presented at all of them, actually.

    Edwards: I’m a supporter. I’m a supporter of the Alan Show.

    Shimel: Well, you know what, to me it’s about bringing these two tribes together. It was something that Gene Kim and Josh Corman tried to do and I’ve tried to help, and Mark Miller and the Sonatype folks. And Damon, you know what, it’s paying off because I spend a lot more time in security just because of my background, and I’m hearing from—I’m not getting the pushback I used to get from people about DevOps any more. They get it. Or they’re starting to get it. God hopes. Anyway, Damon Edwards, we’re way past our time, but that’s okay, it was worth every minute. Thank you for being this episode’s guest on DevOps Chat. We will see you in Singapore. You know what though? For people who want information about Rundeck, where can they get more information?

    Edwards: Rundeck.com. There’s a free trial of Pro. You can always use the open source. We’re on IRC, we’re available, so we’re around. Feel free to reach out to us and we love talking about this stuff.

    Shimel: Cool. Damon Edwards, co-founder, chief product officer of Rundeck Inc., and also DevOps evangelist extraordinaire. Thanks for appearing on DevOps Chat and we’ll speak to you soon.

    Edwards: Thank you, Alan.

    Shimel: All right. This is Alan Shimel for devopsy.kinsta.cloud, DevOps Chat, and we’ll see you soon on the next chat.

    — Alan Shimel

  • DevOps Chat: DevOps, Cognitive, IoT & Blockchain

    DevOps Chat: DevOps, Cognitive, IoT & Blockchain

    CJ Paul and Cliff UIn this DevOps Chat we sit down with Cliff Utstein, director of Offering Management, IBM Cloud DevOps and CJ Paul, distinguished engineer and chief architect, IBM Cloud DevOps. Cliff and CJ give us some insight into how some of the biggest trends in technology today—DevOps, cognitive, IoT  and blockchain—are connected. It is a great discussion with some of the people at IBM who are dealing with these subjects day in and day out.

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

    Audio

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud and we’re here for another DevOps Chat. We have a really interesting DevOps Chat today and it’s regarding how DevOps kinda interacts and can help you get started with some of the leading sort of technology trends out there today and talking about things like cognitive and blockchain and IoT, etc. So a lot to cover in our 15-minute show, but we’re gonna do the best we can. I’m joined today by two friends from IBM. First of all, a returning guest to DevOps Chat, our friend CJ Paul, distinguished engineer and chief architect, IBM cloud. CJ, welcome to DevOps Chat.

    CJ Paul: Thank you, Alan. Glad to be here.

    Shimel: Thank you and welcome – glad to have you here. And, secondly, we have Cliff Utstein, and, Cliff, if I mispronounced your last name, I apologize, but Cliff joins us from Boston and he is the director of DevOps product development for IBM Bluemix and cloud. Cliff, welcome.

    Cliff Utstein: Thanks, Alan.

    Shimel: Did I mess up the title or the name?

    Utstein: I actually lead product management for IBM’s Bluemix – IBM’s cloud DevOps.

    Shimel: I apologize. So much for me for following the show notes. That’s what you get. [Chuckles] But, okay, fantastic. So, guys, you know, three big, kind of meaty topics out there—cognitive, blockchain, and IoT—and then how does DevOps help you get started with all of them. Let’s start with cognitive because, certainly, IBM is a market leader in cognitive and it seems like they’re building cognitive into everything. So let’s talk a little bit about that. CJ, I’ve probably spoken about this with you in the past, so, if you don’t mind, let’s start with you. How can DevOps help you get started with cognitive?

    Paul: Well, we find many customers evaluating several of these cognitive services that Watson provides. They are available as APIs in Bluemix, so this is – such as natural language understanding, natural language classifiers, the Watson conversation service, and many others like that. And many companies are looking at how to take advantage of those combination services to build interesting applications, like chatbots, that they can deploy for various use cases. So, as they look to build these applications, clearly, the way you build these applications is important.

    What DevOps proposes now is an iterative model where you rapidly take ideas and get them into code and deliver them out to market and see how effective they are. And then, you know, measure the usage and iterate rapidly from there, so using the DevOps practices and toolchains that we provide, it can greatly speed up a company’s ability, the developer’s ability, to build and deliver these leading-edge cognitive applications.


    — Alan Shimel

  • DevOps Chat: Developers and Security with Pete Chestna, Veracode

    DevOps Chat: Developers and Security with Pete Chestna, Veracode

    In this DevOps Chat we speak with Pete Chestna of Veracode about the roles and opinions of both developers and security pros about how and who should be working on security in the enterprise. Much of the discussion centers on a survey Veracode conducted with consulting firm Enterprise Strategy Group (ESG).

    Pete is always a great interview with a common-sense approach to DevSecOps borne from being both a developer and security pro. I am sure you will enjoy this discussion. As usual, the streaming audio of our discussion is immediately below and the transcript of our discussion is below that.

    Audio

     

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on the chat is Pete Chestna, Veracode, a CA company, director of developer engagement. And that’s a fancy way of saying Pete’s out there talking to developers about bringing security, shifting it left, bringing it into the developer universe and making all of our apps more secure. Pete, welcome to DevOps Chat.

    Pete Chestna: Thanks, Alan. Pleasure to be here.

    Shimel: Yep. So, Pete, you and I have, of course, crossed paths before and I’ve seen you present and you’re a knowledgeable, knowledgeable person, in terms of how security is continually kind of making inroads into the developer community and kinda convincing them that security’s everyone’s responsibility, right? That security isn’t just the purview of the security team; it’s everyone’s job. And you’re doing a heck of a job with it, which has, I think, attested to Veracode’s value in the market and its place in the market, so great job there.

    Chestna: Thanks.

    Shimel: Pete, what we’re gonna talk a little bit about today is that Veracode recently conducted a survey of developers and security folks, talking about this very subject. And I wanted to share it with our audience a little bit, if you can. Why don’t we start with what you consider sort of the headline of this survey?

    Chestna: Thanks. So this was done with the enterprise strategy group and the key takeaway for this is, really, again, it’s reinforcing the messages we already bring out to the market, so we need increased accountability. The reason that developers don’t take security more seriously is because they’re held to account for their functionality and not necessarily their security, so, if we bring in metrics and goals into the equation, for developers, we’re gonna see an increased uptick in the way they think about security. It’s about building relationships with your security team, so security and developers need to work together to build that relationship, so, that way, they feel like there are people on each side and not just a function.

    And, really, it’s what I call the “three-legged barstool of application security.” It’s about training, making sure developers are trained—a lot of the times that they don’t wanna develop these tools is because they don’t know what to do with the results. Second is integrate and automate—if you bring it into their toolchain and make it easy for them to use, then they’re more likely to use it. And, lastly, it’s about helping them fix what they find—again, this knowledge gap of, “What is across-site scripting? What is OS command injection?” Help them understand how to fix these and prevent them makes them more likely to adopt these tools and make security a better part of their work.

    Shimel: Got it. And you know what, Pete? So I’m up here in Boston, recording this, and we just finished a DevOps Connect. I had an interesting question from the audience yesterday, and a gentleman said, “Well, our developers kinda get paid or judged on how much code they commit. And to go back and tell them that the code they committed, you know, it had vulnerabilities and they gotta fix it, it really upsets them.” I’m sorry for them, right, Pete? But –

    Chestna: Right.

    Shimel: – to me, it’s kind of—you know, I used to see this problem with running sales teams and stuff like that. You’ve mismatched incentives here. Right?

    Chestna: Oh, absolutely.

    Shimel: You know, and that has to be—and that’s not the developer’s or the security guy’s fault; that’s management’s fault.

    Chestna: Yeah, if we don’t take accountability for what we’re doing, if we don’t hold the developers—so, you know, I always look at the security team. They are responsible for security but the developers need to feel accountable for security. And you’re right; it’s management that needs to say, “We’re gonna measure you on this and it’s gonna be part of how we evaluate you at the end of the year.” That will drive the right behaviors. They’re gonna do what they get paid to do. And if they get paid to produce functionality faster, that’s exactly what they end up doing.

    Shimel: Yep. And so this is apparently something, I think, we need to solve. You know, we’re gonna see real progress in the area. But, look, let’s save that for another day. Pete, can you share some more of the findings on the survey with us?

    Chestna: Yeah, absolutely. So a couple of things that stood out to me, as I read through it, was there’s a increased maturity as far as adoption of Agile and DevOps. There’s only 5 percent of respondents that said they have no Agile in their shop at all, where 18 percent say that most or all of their products are using a Agile methodology. And then it goes on from there—28 percent is more than half. So we’re seeing a really good adoption, at least of Agile. And then if you think of DevOps usually being run on an Agile methodology, only 6 percent of respondents says they haven’t adopted DevOps at all and 17 percent are reporting that they have extensively adopted it, so great numbers, as far as people coming up to speed in doing this. And, as far as making things easier, 45 percent of respondents said that DevOps makes it easier for them to developer software, including security, which is a great finding.

    Shimel: That is—what was the number? 45? Just about half?

    Chestna: Yeah.

    Shimel: Excellent.

    Chestna: So those must be shops that are doing it well because they’re seeing the benefits that you get from experiencing DevOps.

    Shimel: Well, I mean, you know, Pete, you take this, I think, in conjunction with the recent release—I was out in London last week for DOES and the folks at DORA and Puppet released the State of DevOps for this year’s survey and results, and it dovetails nicely here, where DevOps-enabled organizations deal with something—I forget what the number was—15 percent less vulnerabilities or 15 –

    Chestna: Right.

    Shimel: It was some –

    Chestna: It was from the Puppet report.

    Shimel: – eye-popping number of the improvement in the quality of code, vis á vis security. So it seems to make sense, but you know what, Pete? I’m amazed that something that seems so, you know, simple, so elementary, if you will, is still—we’re still talking about only half of organizations, a little less than half organizations doing it. What do you think is holding back the other half?

    Chestna: It’s the culture. You know, people wanna maintain their silos. I see it all the time where the management—again, we’re going back to management, as a problem here—they wanna hold on to their silos and their power. And if you look at where DevOps takes a company typically, if you do it whole-hog and embrace everything, you’re reorganizing, so someone that has a large quality staff reporting to them is now gonna have that broken up and disseminated into other teams, and now they’re gonna be responsible for other functions or they’re gonna have to go find another job. So there’s this big unknown and fear for them of, “What does the future hold if I just don’t do quality and I have to actually produce product?” So this cross-accountability is just—is scaring the hell out of them.

    Shimel: Yeah. Yeah. But you know what? Let’s not put it all on the dev side of things; let’s talk a little bit about the security folks, too. And, Pete, you and I both come from the security world. There are a lot of security people who get very territorial, you know, to say the least, around running scans, being the ultimate deciders of what’s secure and not secure, and they’re just as resistant to change, from a cultural point of view, as dev teams are sometimes. I mean, do you agree or –

    Chestna: Yeah, and they white-knuckle the release, so –

    Shimel: Yeah. [Laughs]

    Chestna: – I’ve talked to a lot of people that say, “Hey, it’s gotta be pen-tested. I have to pen-test everything.” If you’re talking about releasing multiple times a day, there’s no way in heck that you’re gonna be able to do that. So you have to pick your battles and say, “This is important. It touches crypto or this touches authentication or authorization. It has to be pen-tested,” versus, “I can use the easy, least expensive way of SAST and DAST to go and find vulnerabilities and I can trust that those tools will find things.” So it’s that back-and-forth of how much security needs to be in there and how assured do they need to feel before they can sleep at night.

    Shimel: Mm-hmm. And they’re ultimately, Pete—you know, I think, when we look at surveys like this and we talk about the view of the security team versus the view of the dev team, view of management, really, the way to kinda bridge these gaps and bring this all together is really a lot of the kinds of things that you do. Right? You’re out there, talking to the different constituencies around the world, almost constantly—we were talking off-mic about how much both of us have been traveling—but there’s a mission there to bring these tribes together, if you will, and forge a common path and a common way of working together. And I think, if we take surveys like this and we look at the results and we share those results with the two teams, again, it becomes sort of like, “Duh. What are we fighting about?”

    Chestna: Oh, exactly. So, I mean, if I go back to the survey for a second here and look at how people are being measured, 33 percent of respondents say, “I’m being measured on functionality that I released,” versus only 18 percent that are saying, “I’m being judged on security.” So, if you look at that number and say, “Well, what are they doing? Their actions reflect how they’re being measured, so let’s change how they’re being measured and see if that changes what they think about their jobs.” The people that responded and looked at “Does DevOps help me with security, the ability to automate and integrate?” 58 percent of respondents said, “Hey, it allows me to do this integration and automation,” which is one step toward getting them to actually pay attention to those results.

    Shimel: Yeah. And 58 percent is a sizable majority.

    Chestna: Yes.

    Shimel: That is Pete, I don’t know if you have the insight on this, but these were large enterprises, primarily, that were surveyed here?

    Chestna: Yes, most of them were—98 percent were 1,000 or more employees.

    Shimel: Okay. Now were there any particular verticals that were highlighted or anything?

    Chestna: The biggest ones were IT at 23 percent and the finance industry at 21 percent.

    Shimel: Oh, okay, there you go. And those are both pretty DevOps-savvy, if you will, or maybe early—no, I don’t wanna use the term “early adopters,” ’cause finance is very rarely an early adopter, but, I mean, certainly, DevOps has taken a strong foothold within the financial and financial services industry, so.

    Chestna: Yeah, and the thing is driving them is really the regulatory compliance, so 53 percent of respondents said that, “We’re doing app-sec because of regulatory.” Forty percent are saying it’s because of corporate governance. And an interesting stat here was 34 percent said it was because of customers or partners, so the great news is people are starting to pay attention to their software supply chain, to say, “Am I getting secure software to install in my environment?” and they’re asking customers to prove that they are. And, hopefully, that also means that outside customers, like individuals, are also looking at security as an important decision in where they go and where they spend their money.

    Shimel: Yep. I agree. I mean, it is interesting stuff, Pete. So, Pete, where do we go from here with this now?

    Chestna: So I think the next step is to continue the journey that you and I are on, of helping security understand development, help development understand security, tell them that they need to build in accountability. It’s built by relationships, so they have to work together. If security starts to teach developers how to do secure development and explains to them how to fix the things that they’re finding, developers are more likely to engage because it’s not this great unknown of “Hey, I don’t wanna go in and fail. I don’t wanna go in and look like an idiot,” or, “I don’t wanna go in and not understand what I’m doing.”

    So security needs to take their part and companies need to understand that training and development and education around security is a carrying cost of having developers. They were never trained to do it and they have to pick that cost up; it’s not like they can just throw them all away and bring in new developers because the developers that they bring in are gonna have the same problem. So getting that education done leads to better engagement, leads to better results.

    Shimel: Agreed. And you know what, Pete? Just a shameless plug on that note: I’m gonna be out in Singapore at the end of July, at the RSA APJ show, putting on another DevSecOps event at RSA, and we’re working with both the local—so it’s interesting. In Singapore, there’s almost a 900-person-strong DevSecOps MeetUp group, which is huge for that area of the world, and there’s an equally-as-big DevOps MeetUp group. And we’re working with both of these MeetUp groups, as part of this event, and we’re really—I’m hoping to really kinda bring these tribes together and make it happen. Of course, I’d –

    Chestna: Sounds great.

    Shimel: – you to come out. You’re in Black Hat at that time.

    Chestna: Yes.

    Shimel: Are you speaking at Black Hat, Peter?

    Chestna: I’m not. I’m doing customer stuff, customer-facing.

    Shimel: Ah, very good. So you’ll be in hot Vegas and I hear Singapore’s pretty warm now that time of year as well. Well, we continue along our mission of spreading the good word, right?

    Chestna: Yes, sir.

    Shimel: as they say. Anyway, so, Pete, we’re about out of time. I know you don’t have the URLs off the top of your head right now, but we will include them in the show notes for people to download the results of the survey and the report, maybe find out a little bit more, but I wanted to thank you for sharing and giving us a little bit of insight into the results. And then keep up the great work, Pete. You do good stuff.

    Chestna: Thanks. I appreciate your time, Alan.

    Shimel: All right, Peter. This is Alan Shimel for devopsy.kinsta.cloud’s DevOps Chat and we’ll see you on the next chat.

    — Alan Shimel

  • DevOps Chat: AI Log Analysis with Gabby Menachem, CEO, Loom Systems

    DevOps Chat: AI Log Analysis with Gabby Menachem, CEO, Loom Systems

    Log analysis has become a big data issue. As we collect and want to analyze more and more information, the amount of data to analyze seems to grow by leaps and bounds. One answer to this issue is AI Log Analysis (apply artificial intelligence). While I will spare you the obligatory “machine learning” references, there are companies that are bringing AI to this issue.

    One such company is a startup from Israel, Loom Systems. devopsy.kinsta.cloud sat down with Loom Systems CEO Gabby Menachem in this episode of DevOps Chat. As usual, the streaming audio of our conversation is below, with the written transcript of our conversation immediately below that. Enjoy!

    Alan Shimel: Hello, everyone. It’s Alan Shimel, editor in chief, devopsy.kinsta.cloud, for another DevOps Chat. On this episode of DevOps Chat, we’re joined by Gabby Menachem, who’s CEO of Loom Systems and comes to us today from Israel. Hello, Gabby, how are you?

    Gabby Menachem:  I’m great. Hi, Alan. Thanks for having me.

    Shimel: Thank you for being our guest today, Gabby. Gabby, I guess we should start with – I’m gonna imagine that folks in our audience are not familiar with Loom Systems, so would you mind giving us just kind of a quick background on Loom Systems?

    Menachem:  Sure. Loom Systems is a platform—a solution, actually, to predict and prevent problems in your digital business. We actually are able to analyze logs and semi-structured machine data for immediate visibility into the company’s digital environment, any environment going from legacy systems to the latest application, your homegrown application that you just wrote. And, by doing that, we can significantly reduce the cost and complexity of working with operational analytics on IT. And, using our tribal knowledge bank, which is called “TriKB,” we’re actually able to find issues proactively using log analysis and bring them to IT’s attention and help them resolve them in minutes, instead of hours or days.

    Shimel: Got it. So, Gabby, just to be clear, is Loom actually the log gatherer—in other words, gathering the logs—or is it just analyze logs that are provided from another solution?

    Menachem:  So that’s a great question and, for the most—in most environments, we’re not focused on gathering the logs, so we come to places, in most cases, where they already collect logs, although our solution can handle the collection of logs as well. What we focus on is the actual analysis, so we find that businesses today have a problem utilizing their personnel that they already have, in order to find a root cause and do root cause analysis of issues in the logs. And, as we all know, when you have a problem and with today’s digital transformation, you have to go into the logs in order to find issues that affect your customers. And so, by using Loom Systems, you’re able to get help with that root cause analysis and you get actionable recommendation on how to solve these issues in minutes. And that’s how you can actually use a solution that helps you with the analysis phase and not with the ingestion or things like that.

    We also provide a way to do collection and all the other features of a log management tool, but it’s not out focus and we’re, to be honest, in most cases, we’re happy to find that businesses have already put effort into looking at logs in a centralized manner. That kinda gives us the signal that they’re already operational and they’re looking at logs as a way to solve issues and find the ROI in that case.

    Shimel: Excellent. So, Gabby, give us an idea what kind of log gathering tools does Loom System integrate with. Is it Splunk and that type of thing?

    Menachem:  So we work, basically, with every tool in the market. I’m not aware of a customer that we went to that we weren’t able to connect in less than 90 minutes, so that’s our claim for fame and you can test us, if you want.

    Shimel: Mm-hmm.

    Menachem:  And it takes us—the main thing with our platform is that, from whatever source that you would stream logs from—it could be Splunk, as you said; it can be open-source tools like Logstash or proprietary tools that are Syslog, for example—and, from there to streaming information into Loom, what would happen is that Loom would parse the logs automatically and find anomalies and trends and can actually alert you on things before it affects your business. So we’re appealing more to the business layer, where we want to connect what IT is doing to what the business is looking for, in terms of understanding users’ behavior, anomalies that affect the customer experience, and, basically, our ROI, in most cases, is measured on preventing churn from customers that are actually looking for a better customer experience with all these businesses’ ongoing and digital transformation. Does that make sense?

    Shimel: Yeah, it makes total sense. So, Gabby, one of the probably most overused terms we’re hearing in the market today, but I don’t see it mentioned in the Loom Systems, is this idea of machine learning, if you will. And, you know, machine learning kinda goes hand in hand with AI and stuff like that. Is that kinda what Loom is doing then, in performing this analysis? Or something different?

    Menachem:  Yes. So the way that we actually are able to do all of that is based on machine learning and AI. We don’t want to use the hype of the words as much as we want businesses to understand that this is actually the future of being able to analyze data, so one of the key hurdles that we see or the barriers that customers experience is that, when you want to analyze information, first of all, you need to get a data scientist, which they’re hard to find these days, and you need to have a good methodology of how to analyze your data.

    And one of the key issues here is that Loom is able, through AI and through the heuristics that we’ve put in, to actually do this for you. So we’re trying to abstract away all the complexities of using machine learning and working with features that most data scientists do today, and, that way, we can actually use your, well, highly skilled personnel, but they are not now proficient with using these machine learning systems. So this is the way for you to use super advanced analytics and AI without having to go through extensive training or something like that. The machine would just act as if it’s a human and as if you’ve got a new IT person in your environment that can actually go through the logs all day, without getting tired, and just alert you, call you, and say, “Alan, come look at this. This looks interesting. And, by the way, when I saw this last, we had a problem with our database and we were able to fix it by applying this patch from Oracle,” for example.

    Shimel: Got it.

    Menachem:  Does that answer your question?

    Shimel: Yes, it does. So, Gabby, give us an idea of—and we realize Loom is a startup, but what is the target? Who is the target customer here?

    Menachem:  So we’re marketing to medium-sized businesses through enterprises. Mostly doing insight sales these days, less of an enterprise sale, per se, but what we’re doing is we’re going to these organizations and we’re talking to anyone from the CIO down through directors and IT leaders and DevOps, in order to explain to them that one of the biggest, most sought after solutions that they were always thinking about, which is “How do I actually find things – surface things that are of interest from my logs without any prior configuration?” So you don’t wanna do the big project of parsing your logs and explaining to a system what is important, what is not. You don’t wanna do all of this that is in the market today, which is based on supervised learning, where you have to give a lot of feedback and explain to the system how things should work. You just want the system to act as if it’s a human and understand by itself what is meaningful and what is not.

    And, with that approach of unsupervised learning with a few feedback loops that we employ, what you can actually get is a very sophisticated tool with a very simple approach to operating it, which I think is what IT operations is looking for all the time. We want the simplicity and—actually, we want the complexity of our environments to not transcend to the complexity of the tools that we use, so simplicity in the tools gives us better way to manage these problems. We don’t wan to suffer from alert fatigue and we don’t want to interact with systems that take years to learn and to know how to operate, and that’s the way that we’re actually able to give better customer experience for our customers and solve issues faster.

    So, today, when we go into a business, it takes us about 90 minutes, as I said, to install and get running. And you see the value from your Loom installation in the same day. Do this either on-prem or in our SAS, in AWS or in Azure, so you have all the possibilities there, and we go to both big businesses, like banks and insurance companies through retail and e-commerce, and down to businesses with 200 people. But our main audience is the medium businesses all over and DevOps leaders that are looking for the next generation of proactive alerting.

    Shimel: Got it. So, Gabby, in a lot of ways, this type of intelligence—you know, I come from a security background and we’re seeing this more and more in security, providing actionable intelligence, analysis of—because, I mean, the good thing about big data is it’s big. We have a lot of data; we’re seeing a lot of things. But trying to make heads or tails of it and boil it down to actionable intelligence is key; otherwise, we just drown in data. How did you guys kinda come up with the idea to do this?

    Menachem:  So, first of all, the big thing here is what you described—the fact that we were—a lot of the team was working in intelligence, in fact, before that, and we’ve seen a lot of this use cases where you’ve had to look at a lot of information and be able to sift through it and find interesting things, in order to bring them in front of a human that can make the business decision.

    So there’s a layering system, where you look at data as the lowest layer and on top of it there’s the what we call “information layer,” which is where all the tools today are. So it’s a way to have a mapping between data and visualization, so let’s take the number of errors that you see in your logs, for example—that could become a graph. And, on top of this graph, what people are doing today is they’re looking at it and figuring out if there’s some anomaly or a trend there that they should be looking at, and then they go back to the data and make sense to out of it. This is the third layer, which is called the “intelligence layer,” and this is where our tool operates. On top of this, there’s one more layer which is called “wisdom,” and that’s where you connect the intelligence layer, which tells you what is going on with a business decision that you have to make, and then you can take action.

    So an example would be—and sometimes we get this question of, “Why don’t you connect this to automation tool to actually resolve issues automatically?” And what we say is that resolving issues is a business decision. It’s not just about, you know, if it’s Black Friday and our system is finding that there are one percent of your users that are experiencing a problem, you don’t want the server to restart because you’re gonna lose a lot of business, so the business decision has to remain in the hands of DevOps leaders.

    And, coming back to why we started this business and how we came up with the idea, it’s basically—I think what happened in intelligence is actually happening in the commercial market, so big data is a new thing in our world, but it’s not a new thing in intelligence. It’s been there for 50 years. And, as the intelligence community grew and came to the conclusion that something had to be brought into a visualization tool, they built this information layer, and then the next phase was to actually build “smart systems,” as people call it today, to analyze information for you and come up with things that people just can’t handle, in terms of capacity. So the cognitive ability that we built into the solution perfectly aligns with what happened in the intelligence community, and now we’re bringing it to the commercial market, for the use of all these businesses doing digital transformation.

    Shimel: Makes sense. Makes sense. So, Gabby, we’re coming on the end of our time—as I mentioned to you, it goes fast. Where can people find out more about Loom Systems?

    Menachem:  So through our website, loomsystems.com, is the best way to get information. You can sign up there or you can even talk to us with a chat online. We provide free trials, so it’s very easy to start streaming information to our SAS business, and we can converse with you and start understanding your use case. We’re very fast to operate and you’d see value in the same day. I invite everyone to come talk to us and you can also meet us at a lot of the industry events. We’re gonna be in OpenStack next week and hope to see you there and talk to you.

    Shimel: Got it. Gabby, just so the audience knows, what is a typical engagement price-wise or how is it priced?

    Menachem:  So it’s based—today, it’s based on the number of instances sending information into Loom, so one of the differentiators, in the way we price this, is it’s not data volume-based, so you can actually send us as much information as you want, unlimited data, and we just count by the number of instances sending information into Loom. And the regular prices, they start at about, I’d say, $20,000.00 for the smallest amount, and most installations are in the $50,000.00 to $100,000.00 on annual deal.

    Shimel: Got it. Excellent. Well, Gabby, thanks for sharing this information with us today and thanks for being our guest on this episode of DevOps Chat. Continued success with Loom Systems and we’d like to hear more maybe, going in the future—if my mail program would stop making noise, we’d be okay. I apologize. Gabby, we’ll check back in on Loom Systems perhaps in a few months and see what kind of—what’s new, but until then, keep doing what you’re doing. This is exciting, kinda representing the future of where we are with analysis and using computers, so congratulations and continued success to you and Loom Systems. This is Alan –

    Menachem:  Thank you very much, Alan.

    Shimel: Thank you, Gabby. This is Alan Shimel for DevOps Chat and devopsy.kinsta.cloud. Thanks for listening, everyone. We’ll see you soon on another DevOps Chat.

    — 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

  • 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

  • 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