devopsy.kinsta.cloud

Author: Alan Shimel

  • DevOps Chat: Gene Kim, DevOps Enterprise Summit London 2016

    DevOps Chat: Gene Kim, DevOps Enterprise Summit London 2016

    I recently had a chance to sit down with author and researcher Gene Kim about the upcoming DevOps Enterprise Summit in London (DOES). This is the first DOES out of the US and Gene and team are planning to make it a great success. Below is the audio of our conversation and below that is a the transcript of the conversation.

    Of course if you are thinking about attending DOES London, you can also attend next week’s DevOps Connect: CD Summit/Jenkins Days and receive a full credit towards a DOES London ticket. A great 2 for 1 sale. BTW, Gene mentions the DevOps Enterprise YouTube channel in our discussion. Here is the link for it: https://www.youtube.com/channel/UCkyYEVVmT9vQ4yPBR4ciFUA

    Enjoy!

    Alan Shimel:                Hi, this is Alan Shimel, devopsy.kinsta.cloud here for a special DevOps chat with Gene Kim, bestselling author, researcher and DevOps personality. Hi, Gene. How are you?

    Gene Kim:                   Doing great, Alan. Oh, my goodness. How about a researcher who loves studying high performing technology organizations.

    Alan Shimel:                Okay. Hi, I’m here with Gene Kim, a researcher who loves studying high performing technology associations and writes a good book.

    Gene Kim:                   Ah, love it. So much better.

    Alan Shimel:                All kidding aside, Gene, it’s a pleasure to have you on our show again. And we’re here to talk about the upcoming DevOps Enterprise Summit, London for 2016.

    Gene Kim:                   I love it. In fact, this has been so fun. It’s our first year in London and so it’s been amazing. Sort of tapping you know the network to find great DevOps transformation stories in large complex organizations. But you know after just a lot of hard work on behalf of the entire programming committee, you know I think it’s shaping up to be just a fantastic conference.

    Alan Shimel:                Yeah. I mean I had a look earlier today at the speakers announced and you know part of me was really happy that I knew a lot of the names of who are these speakers and part of me was really happy that I didn’t know a lot of the names, right. Because you always want to hear new stories and from new people. So I think there’s something for everyone there. But Gene, you know what I’ve had the pleasure and honor of being on a program committee with you for the RSA Rugged DevOps event we do every year and so forth. But a lot of our listeners may not really understand what goes on behind the scenes and how do you get great speakers. Would you give our listeners just a little bit of like pull back the curtain a bit and talk to us about how you always come up with great speakers?

    Gene Kim:                   Yeah. You know in fact, so let me first acknowledge the amazing programming committee that we have. One of them is Owen Gartner who is part of the DevOps initiative at Barclays Capital. Ben Grinnell, he’s at North Highlands Consulting Firm. There’s Marco Swindell from Accenture. There’s Benjamin Wootton from Sendachi Consulting. And then two committee members from the U.S. DevOps Enterprise Summit, which is Damon Edwards and John Willis, who are both a part of the DevOps movement from the very beginning. So the job of the programming committee is really to shape and to kind of form the vision of the conference and shape the talks to help achieve those objectives. And I think what’s been different about the DevOps Enterprise Summit is that you know we really aim to create a vendor neutral conference that really focuses on the technology leaders who are driving DevOps transformations in large complex organizations.

    And so it means that with some rare exceptions, you don’t have a lot of the speakers from the DevOps community speaking because they’re not you know in large complex organizations. And so you know the challenge really was to find these amazing stories out there of people driving these audacious transformations in you know very conservative organizations. And you know for that you need people who aren’t just well networked in the industry and in the local market. And so you know we spent, my goodness, five, six weeks just you know scouring our rolodexes, brainstorming about all these – this is where we’ve heard about DevOps transformations going on and then actively reached out and you know vetted them just to gain some assurance that you know they weren’t just talking a good game, but they actually had _____ to show for it.

    So you know as a first year conference, you know there was just a tremendous amount of work that went into that.

    Alan Shimel:                Sure. And Gene, you know to me it’s obvious why London, right. You know when we look at our own Google Analytics here at devopsy.kinsta.cloud, London is the second biggest city from an audience perspective for us. But I’m curious, why did you pick London?

    Gene Kim:                   You know it was because that was actually one of the feedbacks that we got from our speakers and attendees, that you know because we’ve had the DevOps Enterprise Summit now going into the third year in San Francisco on the West Coast of the United States, that is a very long way to travel from people in the UK or from the European continents. So you know the ask was, hey, can you hold it somewhere in the European Union, whether it’s in the UK or in the EU. And so we were actually considering London, the Netherlands and there might have been a couple other options, but ultimately we decided to do it in London just because that’s where our network was. And when I say the network, that’s where the program committee was and that’s where I think our network was strongest. Which was very important because I think it gave us the best chance for succeeding and generating you know the right programming, the right speakers and so forth, the right transformation stories.

    Alan Shimel:                And you know what, I’ll reiterate it. London is a fantastic town. The DevOps scene there is just happening. Not to date myself and sound all groovy, but it’s a happening scene and it’s a vibrant dynamic DevOps community as well. So I think you couldn’t have picked a better place to do it in, Gene.

    Gene Kim:                   You know it’s just a huge center of economic activity. You have a huge financial services industry. You have basically every type of you know industry vertical that are operating, you know in and around London. So, yeah, I agree, it was a great – and also where so much of the progressive DevOps activity is going on within government agencies. Like the UK.gov, the UK Digital Services, all that pioneered inside the UK government.

    Alan Shimel:                Absolutely. You’re a hundred percent right there, Gene. So, Gene, listeners who are listening to this, maybe they haven’t quite decided if they want to go to does London or not. Give me right now, have all the speakers been released or announced at this point or no?

    Gene Kim:                   No. And we’re about 60 percent announced.

    Alan Shimel:                Right.

    Gene Kim:                   But I can certainly share with you the talks that I’m super excited about.

    Alan Shimel:                Go ahead.

    Gene Kim:                   You know one of them is Ron van Kemenade. You know so he is famous for his work at ING as the Global CIO. And so many of us in the DevOps community were aware of the ING DevOps Days that was held in 2011. In fact, that was probably the event that kicked off the first Target DevOps Days and the first DevOps Days at Capital One. You know it was such a novel concept. And so Ron van Kemenade as the CIO, will be talking about you know their journey when ING back in 2011 was very much like Parts Unlimited and the Phoenix Project. You know it was certainly very different from the organization they’ve become where they’ve created a world class technology organization that is widely admired. And so I’m excited that he’ll be talking about his role as the technology leader and to tell the whole inside story of how that transformation happened. And I’m particularly excited that I’ve asked him to share you know in his mind, what does it mean to be a technology leader. You know it’s not about picking Cassandra over Redis, versus Zookeeper, versus NoSQL, versus you know MySQL, right.

    So what does it mean? I think that’s not well understood and certainly not well understood by me. You know there’s a talk from Robin Hughes from LV. So that’s the Liverpool Victoria Insurance Company. So multibillion pound turnover company. So again, an organization that’s been around for over a century and you know this is just a phenomenal DevOps transformation that was really driven by the operations team. And Robin Hughes will be telling the story about how they transformed one of the largest business applications inside their portfolio and enabled developer productivity. So I think that’s great. Anthony Collard, he’s the Deputy Director at HMRC. So that’s the Majesty’s Revenue Collection. So in the US we would call it the IRS, Internal Revenue Services. And you know they have over 60 scrum teams now working to help make life better for tax payers. Whether it’s the people at home or within businesses. And it’s just an incredible story about genuine innovation and creation of phenomenal efficiencies that you know haven’t been typically associated with the way government operates.

    In fact, I was so inspired by it, I actually wanted to voluntarily pay UK taxes just to reward these amazing efforts.

    Alan Shimel:                Don’t count me in on that one, Gene. Thanks. But it’s good for you. Let me also just throw a couple of other names that I recognize and got me all excited. One is actually a friend of mine that I’ve worked with, Jonathan Fletcher over at Hiscox.

    Gene Kim:                   Right.

    Alan Shimel:                I don’t know how much you know about Jonathan, but he’s brilliant. He’s not the – I don’t want to say the suit, but he’s not the title who leads the entire DevOps transformation there. But that person relies on Jonathan to make it happen. ‘Cause I’ve looked at that organization. This guy, I love listening to him talk about what they’ve done there.

    Gene Kim:                   And it’s another phenomenal story. Another insurance company.

    Alan Shimel:                Yep.

    Gene Kim:                   And I think what makes them so remarkable, so obviously they’re a multibillion British pound turnover company. But again, over 100 years old. And yet they’re growing at 30 percent in certain market segments.

    Alan Shimel:                Yes.

    Gene Kim:                   When that’s happening its putting tremendous pressure on the technology organization, you know for them to deliver what the organization needs. And so here’s an incredible effort initiative, where they – and this one is driven by kind of an operations platform and architecture that is enabling development teams to respond quickly to the market and scale with demand. Yeah.

    Alan Shimel:                Yeah.

    Gene Kim:                   I love that Hiscox story.

    Alan Shimel:                Yeah. No. The thing about Hiscox is you know though they’re UK based most of their business is on the continent. You know they have a large presence for instance in the Caribbean as well as the Western U.S. So this is a global organization dealing with regulations and I mean its insurance. I don’t want to tell well, too much on them and Fletcher, Jonathan is a tremendous, tremendous talent. I’m sure it’s gonna translate into a great presentation. Another one Gene, that I wanted to highlight if you don’t mind me stealing a little bit from you, is Gareth Rushgrove, you know who’s at Puppet now. But you know Gareth, besides curating the DevOps weekly newsletter, you know he has a great security background like we do, Gene. And I can listen to him all day.

    Gene Kim:                   Yeah. And what’s great is that maybe not so well known is that he was part of the early UK.gov effort.

    Alan Shimel:                Yes.

    Gene Kim:                   Where he had to deal with all of the regulatory and compliance bodies inside you know a very powerful central government, as well as the intelligence agencies. And so the fact that he was able to span those boundaries and earn the trust of those agencies and essentially help define kind of the next generation of security standards and strategies, is just a really inspiring one. It’s just a really neat guy.

    Alan Shimel:                Yeah. He’s a rock star. I just wanted to mention two others Gene and they’re from DevOps San Francisco who are I guess coming over to London. And that’s Jason Cox from Disney and Rosalind Radcliffe from IBM. Just two brilliant people and I just appreciate brilliance. So you know looking forward —

    Gene Kim:                   I love them both.

    Alan Shimel:                I’m sorry what, Gene?

    Gene Kim:                   What I love about the conferences if you take a look, this is like a great cross section across you know almost every industry vertical. So you’ve got Unilever from you know the consumer goods on the financial services. You have   Barclays from _____ –

    Gene Kim:                   – insurance companies. You’ve got Pearson Publishers. News UK is another publisher. Thomas Cook Group does retailing and travel services.

    Alan Shimel:                Yes.

    Gene Kim:                   Zurich Insurance. You know actually I never realized we have so many insurance companies. So we have 26 speakers announced. You know I’ll tell you another part of the programming committee is that a lot of these we handpicked from people from our own investigation. But then we also had I think it was about 80 submissions through our call for presenters. And so you can imagine how challenging it is when you have only 25 speaking slots, of which over half had already been taken.

    Alan Shimel:                Yeah.

    Gene Kim:                   You can imagine the vigorous debate about you know which talks really need to be a part of the programming. And I just very much appreciate you know the candor and the fact that everyone had the best interest I think for the attendees in mind as we were trying to figure out how do we create the best program for the technology leadership community around DevOps.

    Alan Shimel:                Yeah. And debate is a kind word. Gene, let me –

    Gene Kim:                   Yeah.

    Alan Shimel:                – pivot a little bit ’cause we’re running low on time. So we’ve got this great lineup of speakers. We’ve hit a bunch of them and there’s more yet. But okay, if they attend DevOps Enterprise London, what are they taking out of it. Give me three bullet points. What are the three lessons? What are the three most important things they’re taking out of their attendance at this event?

    Gene Kim:                   Yeah. I think the most important thing is that they are going to hear transformation stories of organizations that look like them. So I think in the DevOps community we’re very used to hearing stories from you know Google, Amazon, Facebook, Etsy, Netflix and so forth. But if you’re in a large insurance company that’s been around for over a hundred years or a government agency that’s been around for five hundred years, you know they don’t relate very well to those unicorns. So to hear how those same type of technology transformations have occurred in large complex organizations, that is the mission of the conference is to share 30 minute experience reports where each speaker shares what business problem were they trying to solve, where did they start and why. What did they do and what were their outcomes and what do they still not know how to do and what are they looking for help with. So, yeah, I think what I’ve heard over and over again is that you know these stories, when you go to this conference you’re surrounded with people just like us, right. Or rather just like me.

    I think the second thing that they’ll hear is that they’re achieving the same sort of outcomes you know in these large complex organizations that we’ve only typically seen in the unicorn organizations. But there’s an element to me that has a tremendous amount of significance and meaning is that each one of these leaders, even though they were given some degree of air cover, I mean it’s as much true for the London conference as for the two previous conferences in the U.S. Each one of these leaders I think wildly exceeded the air cover they were given. Essentially putting themselves into some degree of personal jeopardy. And so when you ask why would they do that? What you see that each one of these speakers have in common is that if they have a sense of utter clarity and conviction that the capabilities that they’re creating for their organization are needed in order to win in the marketplace, let alone survive in the marketplace. So there’s kind of this other dimension of just the hero nature of these stories that I just find so inspiring. And it’s been an honor to help chronicle.

    Alan Shimel:                Excellent.

    Gene Kim:                   Oh, and I guess the third dimension is like to see the value they’re creating. And I would suspect that in the London conference it’s going to very much match the U.S. conferences, where we’ve observed that one out of four of the speakers at the DevOps Enterprise has gotten promoted in the last three years. Many of them more than twice.

    Alan Shimel:                What a great metric.

    Gene Kim:                   Yeah. This is a reflection of you know I think the value that they’re creating is being recognized by their organizations and they’re being asked increasingly to try to replicate that across a broader portion of the organization and help elevate the state of the practice.

    Alan Shimel:                Fantastic. Well, if that’s not enough to get them to attend to DevOps Enterprise, London, Gene, I don’t know what is. But we’re almost at the end of our time here and we’re gonna have to wrap up. I just want to quickly mention for our devopsy.kinsta.cloud audience, that we will be out there and working with Robin and Todd and the team on setting up an interview area where we’ll be doing interviews with many of these speakers when they come off stage. And much like we did in San Francisco last year and also just hearing some great insights and stories from these folks.

    Gene Kim:                   Yeah. By the way, I’m hoping you’ll post in the show notes, I actually love the devopsy.kinsta.cloud interviews that you did. And so we have them all on the YouTube channel, where you can actually see all of your interviews Alan.

    Alan Shimel:                Yep.

    Gene Kim:                   As well as all the DevOps Enterprise talks from the years past.

    Alan Shimel:                Absolutely.

    Gene Kim:                   So I think it’s just a phenomenal resource for anyone who’s interested in this topic.

    Alan Shimel:                And that’s the DevOps Enterprise Summit YouTube channel.

    Gene Kim:                   Correct. Yes. And the link will be in the show notes.

    Alan Shimel:                Fantastic. I’ll put it in there. And I’ve actually featured many of them over the months on devopsy.kinsta.cloud. You can find articles and embeds and links to it as well. But Gene, let me let you go because I probably took up more time than I was supposed to. I apologize. We’re really looking forward to a smashing DevOps Enterprise Summit in London.

  • Jenkins Creator Kohsuke Kawaguchi (KK) at DevOps Connect: CD Summit Dallas

    Jenkins Creator Kohsuke Kawaguchi (KK) at DevOps Connect: CD Summit Dallas

    I haven’t written much about some of the great content and sessions that have been held in our DevOps Connect: CD Summit/Jenkins Roadshow. We have held them in Dallas, Chicago and Boston. Each event was different, but all featured some tip top speakers. One of the “regulars” at our events has been Kohsuke Kawaguchi or KK as the Jenkins world calls him. KK is the CTO of CloudBees and the creator of Jenkins. He is also one of the more intelligent people I have ever had the pleasure to meet. On top of this his humble nature only enhances his overall stature. I wanted to post a short interview I did with KK at the Dallas DevOps Connect: CD Summit/Jenkins Days. We hope to have his full keynote available on our DevOps TV YouTube channel soon as well.

    Below is the the video of my interview with KK and below that is a transcript to read along as well. Also a quick reminder next week (May 23 & 24 and May 25) we are in London and Stockholm continuing this fantastic road show. Next fall we will be in 8 or 9 more cities as well. Check out DevOpsConnect.com for dates.

    Alan Shimel:                Hi, this is Alan Shimel, editor in chief at DevOps Connect CD Summit Jenkins Days in Dallas. Happy to be joined by KK, the founder of Jenkins and CTO of CloudBees. KK, thank you.

    KK Kawaguchi:          Oh, thank you very much for having me.

    Alan Shimel:                Thank you – well, it’s our pleasure to have you, but you are just coming out of the Jenkins track that you delivered, which was a very technical track on Jenkins and your keynote this morning was on continuous delivery pipeline and we spoke about Jenkins 2.0 as well as local Jenkins as a service and Jenkins certification. And what was the last one where we give you the whole package that we’re going to not certify, but what was the word?

    KK Kawaguchi:          So you call that the CloudBees Jenkins platform, private label solution basically.

    Alan Shimel:                Absolutely. So, for our listeners who weren’t lucky enough to be here, can you – I’m not going to ask you to do the whole 45 minutes, but can you give us a – just in five minutes, sort of the highlights of each, of what we spoke about?

    KK Kawaguchi:          Yeah, so Jenkins version two, like, we are trying to move to dial  in three key areas. The one is the continuous delivery through the pipeline of code, so we want people to be able to define this choreography of orchestration, AKA, the continuous delivery pipeline as a series of text files. And then they can put that into version control system and monitor them well. So that’s one of the sort of key features in Jenkins 2.0.

    The second one is this more curated out of the box experience. So we want new people who are starting Jenkins today or tomorrow to start with this 80 percent, like a richer set of functionality that represents the 80 percent of the use cases so they have right out of the box, they get something useful and they can get a lot of mileage from. And then at some point, they would start leveraging this great ecosystem in Jenkins. So that’s this out of box experience is the second part.

    And then the third one is some of the GUI improvements. You know, Jenkins is something people will use every day, so we wanted to make sure that we keep up with this progress in the frontend technology. So that’s something we’ve been doing. So those are the three key pillars to the new release.

    Alan Shimel:                And I think you said that fingers crossed, we’re looking at the Jenkins 2.0 or CloudBees 2.0 in the end of this month?

    KK Kawaguchi:          Yeah, so the Jenkins 2.0, we are – we’ve been working on this for a good while now and we are at the final home stretch. Today is actually the release candidate day.

    Alan Shimel:                Really?

    KK Kawaguchi:          Yeah, and then in two weeks, if nothing bad shows up, and that’s the part where I’m crossing fingers, nothing bad shows up, in two weeks, we are shipping the 2.0 GA.

    Alan Shimel:                So as you mentioned in your keynote, as someone who started this as a little project for your three, four man team inside, I imagine there’s a tremendous amount of price in seeing what this has become and –

    KK Kawaguchi:          Yeah. Yeah. Little did I know that the itch that I was scratching was shared by so many other people.

    Alan Shimel:                Yep, hundreds of thousands, really.

    KK Kawaguchi:          Yeah, exactly.

    Alan Shimel:                What was the number, 100,000 active installs, 400,000 computers?

    KK Kawaguchi:          Yes, that’s right. I think the exact number I believe I think is 120,000 or something, but there’s a massive number of people using Jenkins to, I guess to help move their – to help deliver software faster and I’m really proud of being a part of that.

    Alan Shimel:                Fantastic. KK, one last question. Many of our listeners and readers out there, they’ve heard of Jenkins. They’ve heard of continuous delivery. They may not know how to get started with it. For someone just looking to get started, what’s the best way?

    KK Kawaguchi:          Right. So if you are really new to the whole, you know, whole CICD, then I think that the very easiest place you can start is, well, you know, the install Jenkins, it’s really easy to just really get it installed or you have it installed and so you can start one up and then you put the – like an automated build up on every commit.

    So, everyone already has a build screen because that’s going to run that every time someone commits a change, even something that simple, which only takes like 15 minutes, it’s going to pay a lot of dividend.

    And then once you get this idea across to your team that well, a little bit of automation helps, then you can like incrementally go a little bit by little bit over time. So next step might be running tests. Maybe that could take a lot of, you know, multiple phases. And then that’s how I start on the, like, how Jenkins spreads inside some microsystems is really where that came from. That’s how Jenkins got into so many places and that’s how people are doing it, one thing at a time, sort of a little bit over a little bit.

    Alan Shimel:                Excellent. KK, thank you so much for your time. Thank you for sponsoring, CloudBees for sponsoring our CD Summits and we look forward to seeing you in future CD Summits as well as Jenkins 2.0.

    KK Kawaguchi:          Yeah, thank you very much and me too.

    Alan Shimel:                Thank you. This is Alan Shimel for devopsy.kinsta.cloud.

  • London Calling: DevOps Enterprise Summit and DevOps Connect: CD Connect/Jenkins Days, 2 for 1

    London Calling: DevOps Enterprise Summit and DevOps Connect: CD Connect/Jenkins Days, 2 for 1

    As is to be expected from a world capital city, London is also a hotbed of DevOps adoption. The local London DevOps community is thriving with a near constant stream of DevOps conferences. There are however two great events coming up that are can’t miss. DevOps Connect: CD Connect/Jenkins Days in May and Gene Kim’s DevOps Enterprise Summit in June are both in London. Now you can attend both for the price of one!

    Right now due to the devopsy.kinsta.cloud sponsorship of DOES London and the generosity of the sponsors of both events, if you sign up for the full £179 two-day ticket for DevOps Connect: CD Summit/Jenkins Days you will receive the full £179 back in the form of a credit towards your ticket for DOES London. You wind up attending CD Connect/Jenkins Days for free!

    So what do you get from attending DevOps Connect: CD Summit/Jenkins Days and the DevOps Enterprise London? Glad you asked. Let me give you some of the highlights to look forward to.

    First DevOps Connect: CD Summit/Jenkins Days:

    1. Two-day event, day one features keynotes and three tracks, plus lunch, refreshments, exhibit area and demo theater.
    2. Day two of the event are deep dive workshops on Jenkins, DevOps Transformation, automating deployment in Hybrid Clouds, DevOps Foundation and DevOps Lift off and the Nexus World Tour: Rugged DevOps Heroes Assemble. You can pick and choose which of these workshops to attend, there is on price for admission to all of them.
    3. The event is being held at the KIA OVAL, KENNINGTON OVAL,SE11 5SS LONDON, UNITED KINGDOM.
    4. The keynote and headline speakers for the event are pretty amazing:

    sacha-laboureySacha Labrourey, CEO and Founder CloudBees, former CTO JBoss speaking on “Why Jenkins Has Become the Engine of Continuous Everything.”

     

     

     

    sanjeevSanjeev Sharma, CTO & Distinguished Engineer for DevOps, IBM on “Adopting DevOps at Enterprise Scale.”

     

     

     
    garyGary Gruver, Author of “Leading the Transformation”, Previously executive IT positions at Macy’s and HP, speaking on Leading the Transformation: “Applying Agile and DevOps Principles at Scale.”

     

     

    After this great morning of keynotes, there are three tracks all full of great speakers and topics after lunch.  You really don’t want to miss this event and if you were planning on going to the DevOps Enterprise Summit London, you can go to CD Summit/Jenkins Days for free.

    Why go to DevOps Enterprise Summit London? Well if you want to hear about the experiences of large enterprises in adopting DevOps, there is no better place. In the previous two Summits held in San Francisco, Gene Kim and team have done a great job of shining a light on “horses” DevOps transformations. This first London edition of the franchise promises to be equally as great. It will be held at the Hilton Metropole in London.

    Some of the speakers scheduled to present include:

    geneGene Kim, Author, Researcher and Founder of IT Revolution.

     

     

     

    gareth

    Gareth Rushgrove, Senior Software Engineer, Puppet.

     

     

     

    jasoncox

    Jason Cox, Director, Systems Engineering, The Walt Disney Company.

     

     

     

    This is just the tip of the iceberg really. There will be over 25 speakers at DOES London, as well as community space, breakout sessions and more.

    While London has more than its share of DevOps events, I am not sure it has experienced the likes of these two events before. Please don’t miss them and look forward to seeing you there.

  • A Panel Discussion On What DevOps Looks Like In 3 to 5 Years?

    A Panel Discussion On What DevOps Looks Like In 3 to 5 Years?

    With all of the hype around DevOps, I wanted to return to a topic that I was lucky enough to moderate a terrific panel on at IBM InterConnect this past February. The panel was an all star one anchored by Gene Kim, moderated by myself and we were joined by Dan Berg of IBM, Michael Azoff, principal analyst at Ovum and Raghunath Raman of Kaiser Permanente.

    It was a lively discussion as we all had our own opinions on where DevOps may be headed and how this will impact how we do business. Unfortunately this panel was not video taped, so I cannot share it with you here. But I did get a chance to sit down and discuss this topic with three of the four panel members (I was not able to catch up with Gene as he was running right after our panel).

    So I wanted to share my discussions with each of the panelists with you. First is Raghunath Raman of Kaiser Permanente:

    Next up is Michael Azoff from Ovum. Also you may want to check  in a subsequent DevOps Chat I did with Michael a few weeks ago.

    Finally, last but certainly not least is IBM’s Dan Berg who I have had the pleasure of interviewing several times.  Dan’s interview was done a little later at the show, so is less focused on our panel subject. Our discussion on the panel comes in at about 2:58. Here is Dan’s interview:

    So what about the panel? Some of the highlights were that containers and microservices are going to become a major factor in development going forward. They won’t replace hypervisors totally, but they will become the defacto standard for building and deploying apps.

    Several of the panelists said they didn’t know if DevOps would be called out as DevOps anymore, it would just become the way things are done (something I very much agree with). Of course Gene was full of antidotal stories and studies of companies he has spoken with who are adopting DevOps. All in all the 45 minutes was way too short to dig in as much as one would like with four great panelists, but the standing room only crowd certainly got a lot to chew on.

  • DevOps Chat: Mike Pittenger, Black Duck Software on Open Source and DevOps

    DevOps Chat: Mike Pittenger, Black Duck Software on Open Source and DevOps

    I recently had a chance to speak with Mike Pittenger, Vice President of Strategy for Black Duck Software. Black Duck is a company that I have been following for many years. They pioneered the idea of auditing open source usage to ensure compliance with licenses and such. Of course over the years they have expanded into other areas as well, including security, DevOps, containers and more. Mike and I discuss Open Source and DevOps.

    Mike and I had a good conversation I hope you will enjoy. You can listen below or follow along with the transcript below that.

    Alan Shimel:               Hi, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Today’s guest on the chat is Mike Pittenger of Black Duck Software. Mike, welcome.

    Mike Pittenger:            Thanks very much, Alan. Nice to be here.

    Alan Shimel:                So, Mike, our audience, you know, I’m sure many people in our audience have not met you before, unless you’ve invited your relatives. But can you give us a little background on who you are, Mike, and your role with Black Duck?

    Mike Pittenger:            Sure, sure. So I’ve been in the software security space for about 16 years. I started with @stake back when it was a leading software security consultancy. I ran the product team there, and then when Symantec acquired @stake I spun off that team to form a company called Veracode. I stayed there for a couple of years and then started consulting work with Bit9, Digital Guardian, BeyondTrust, Coralogix.

    And Black Duck was a customer of mine – a client of mine – about two years ago and we were involved in a discussion of product enhancements and so on. And I came back to them about a year ago. They called me back in for another project and I found the opportunity so interesting that we – I came on full time to head up their security strategy.

    Alan Shimel:                Very good. And Mike, believe it or not there may be some folks in our audience who aren’t familiar even with Black Duck.

    Mike Pittenger:            That would be hard to believe, Alan. [Laughs] We’ve been around since –

    Alan Shimel:                A long time, I know. I’ve been writing about you all for a long time. But that being said, just in case let’s give them a little background.

    Mike Pittenger:            Sure. The company is about 13 years old and what we’re very good at is looking at source code or binaries to identify the open-source components that are used in that. Once we’ve identified those we can tell the customer anything they want to know about because we track over open-source projects and we’ve been doing it for about 13 years.

    For the first 10 or 12 years of the company’s life, the primary interest in this was the people would run our software internally in order to determine the open source, but they were interested in it because of license compliance. They wanted to make sure that they weren’t using reciprocal or restrictive licenses like GLP code and _____ distributing; something that might put their own IT at risk.

    About five years ago we started adding security information from the National Vulnerability Database and a year ago we came out with a product specifically focused on security. It’s a big deal because while license compliance is still an issue for risk managers, open-source software, because it’s become so ubiquitous, is also a concern to security people.

    There are – there have been over 4,000 new vulnerabilities – excuse me, over 6,000 new vulnerabilities reported in the National Vulnerability Database just in the last two years. So unless people are aware of the software they’re using and the components they’re using in that software, they’re unable to protect themselves from these vulnerabilities and that’s where we come in.

    Alan Shimel:                Excellent. So Mike, I wanted to talk to you a little bit today about open source. And certainly open source vulnerabilities and scanning are big topics today, especially when we talk about that in the context of containers. And I know Black Duck is actually doing some work around container security and vulnerability scanning, etc. But I wanted to just take it up another 50,000 feet and talk overall open source’s – open source’s role in this whole DevOps revolution/evolution, if you will. Can you talk about that?

    Mike Pittenger:            Sure. Yeah, so I mean the big thing, of course, is that a lot of these particular – with the popularity of containers, a lot of those are running on a lightweight version of Linux, and of course that’s open source. Where we see the risk with that is not in using Linux, it’s whether an open-source operating system or component is more or less secure than a commercial component. It becomes a religious argument and you can argue it until the end of the day.

    The fact is you just need to have awareness of what you’re using and monitor that closely. So we did an informal study of the containers on Docker Hub and found that most of them, the majority of those, had security issues with them. And it was easy to see how this happens because containers are constructed just like software is constructed. People are pulling in often open-source components and they build a LAMP stack and add their application to it.

    If they’re going to deploy a new application they may strip off the application layer, maybe strip is right down to the Linux core again, and then build it back up. But if they’re reusing these components and a vulnerability happens to be in there from the beginning, or one is disclosed after you’ve built that initial container, it’s just going to propagate itself. So people are justifiably concerned, I guess is the right word, about the security of these.

    And from our position, it’s really more about understanding the hygiene of the container, understanding what you’re using, and then monitoring that closely because with 6,000 new vulnerabilities in a two-year period, clearly your security posture can change without you doing anything.

    Alan Shimel:                Absolutely. Mike, what we’ve seen in – you know, it’s funny. I was just going over the results of a survey we’re going to be releasing soon about DevOps tools adoption. And it was split between large organizations, over 10,000, and then about an equal number of under 200. So sort of dumb-belled with not a lot in the middle. But fully 25 percent or more, of all of the tools that these people were bringing in, whether they be – let’s call it a legitimate software supply chain or in through the back door, if you will, shadow – 25 percent of them or more were open source.

    Mike Pittenger:            That’s actually lower than what we see.

    Alan Shimel:                Really?

    Mike Pittenger:            So we have a portion of our business, Black Duck On-Demand. So we’re often brought in during an M&A transaction. So if I’m going to buy your software company, I’m going to “Black Duck it.” They use it as a verb. I’m going to Black Duck it to understand the risk associated or whatever risks there might be. And so these are commercial applications. You assume they have plenty of proprietary value because somebody else is interested in acquiring that company.

    And even in those cases we’re seeing that the code base, 35 percent is open source. If you’re talking about an in-house application that, say, a bank is running, they’re building the applications, consuming them themselves, it’s not unusual to see those applications comprised of 70-80 percent open source. And it only makes sense that they’re doing that.

    I mean, open source is saving them from having to build this functionality from scratch, so it’s providing critical functionality without an acquisition cost. So it’s shortening the time to market and it’s lowering the development cost. It makes perfect sense that they’re doing this.

    Alan Shimel:                Got it. I’m surprised to hear. I thought 25 was a big number. You’re saying it’s a small number and it’s pretty significant.

    Mike Pittenger:            Yeah. It is a small – so if you look at those commercial applications – and we’re going to be publishing a report of our own pretty soon on those – but the average number of discrete open-source components in those applications is over 100.

    Alan Shimel:                Got it. Hmm…crazy. Mike, I want to just – believe it or not, as I told you before we started recording, our time here goes so quickly and we’re eight-nine minutes into our recording. I wanted to just quickly pivot into the whole container and open source and security around it and some of the things Black Duck is doing. Again, people in our audience may not be familiar. Would you give them a little – just a little taste of it?

    Mike Pittenger:            Sure. So we have partnerships with both Red Hat and Docker. In the Red Hat world we’re partnering with them for security on their open shift platform as a service and their container platform Red Hat Atomic. And the idea there is simply to be able to quickly assess the security of a container before you deploy it. So we can run our scan client as a container, pull in a Docker image from a repository and scan it before it’s deployed. Very simple.

    From our world, you can point Black Duck at a container, you can point it at typically a development process that’s integrated with a build server. But you could point it at a repository if you wanted to, and to us, a container is simply another code location _____ scanning. And when we’re looking at that, we’re not just looking at the components, we’re also looking at what makes up those components and are able to identify these down to the patch level.

    So instead of saying you’re using a bad version of _____ and Linux, we can actually look at each of the components and tell if those have been patched for reported vulnerabilities just to make the DevOps manager’s job faster, understanding what they need to worry about and what they don’t need to worry about.

    Alan Shimel:                Got it. Excellent. And you know, Mike, we only have about a minute or two left here, but obviously it’s a dynamic situation – the whole container thing, the whole what’s happening with DevOps and open source and all of this. If you can gaze into a crystal ball, where do you see us going in the next three to five years with this? Where do you see it heading?

    Mike Pittenger:            Well, I think the containers are going to obviously grow rapidly. We see some – it’s a hesitation in deploying, to switching over to containers in some worlds, but I think it’s simply trying to understand it better. An analogy might be people switching over to cloud computing a number of years ago. They want to understand both the benefits and the risks before they throw in all of their chips on it.

    So we see some of the very large companies embracing it aggressively, but a lot of the, say in the financial services industries, still testing it, playing with it, seeing – trying to decide when they’re going to jump in and whether they’re going to start in the shallow end of the pool or go right to the deep end.

    Alan Shimel:                Got it. Got it. Believe it or not, Mike, we’re at our time limit. I know it seems to go so quick. But I wanted to thank you for appearing today, and you know what? If people want to find out more about Black Duck, quick plug for their web site?

    Mike Pittenger:            Yeah, sure. It’s BlackDuckSoftware.com. We do provide a – there’s a free trial that will work on an application or on a container and you can sign up for it right on the web site. It’s www.BlackDuckSoftware.com.

    Alan Shimel:                Perfect. Mike Pittenger, Black Duck Software. Thanks for being today’s guest on DevOps Chat.

    Mike Pittenger:            Thanks very much, Alan. Nice to be here.

    Alan Shimel:                Okay. This is Alan Shimel for devopsy.kinsta.cloud.

  • DevOps Chat: Software Lifecycle Management with Michael Azoff, Ovum

    DevOps Chat: Software Lifecycle Management with Michael Azoff, Ovum

    I had a chance to sit down with Michael Azoff, principal analyst for Ovum. Ovum just released a set of matrices that Michael was the author of on ALM, DevOps release management and one on Agile project management. Taken together they provide some great insight into the entire software lifecycle management space.

    I had a chance to view the reports before speaking with Michael and you can too courtesy of IBM. Here are the links:

    1. Ovum Decision Matrix: Selecting a DevOps Release Management Solution, 2016-17
    2. Ovum Decision Matrix: Selecting an Application Lifecycle Management Solution, 2016-17
    3. Ovum Decision Matrix: Selecting an Agile Project Management Solution, 2016-17

    Here is my conversation with Michael. Below is a transcript so you can follow along if you like as well.

    Here is the transcript of our conversation:

    Alan Shimel:                Hi, this is Alan Shimel of devopsy.kinsta.cloud.  Very happy to be joined today by Michael Azoff, principal analyst at Ovum.  Michael, welcome to DevOps Chats.

    Michael Azoff:             Thank you very much, Alan.  Pleased to be here.

    Alan Shimel:                Thank you.  Michael, you – well, Ovum, but you as the author, just published several Ovum decision matrices – I guess plural of “matrix” – in the last day or two, one of which was on DevOps, Agile, et cetera.  For our audience who may not be familiar with the Ovum decision matrix, can you explain kind of what they are, who the audience is, what they’re about?

    Michael Azoff:             Sure.  Yeah, absolutely.  So the Ovum decision matrix is Ovum’s product comparison methodology, where we compare products side by side, across three dimensions – one is the technology; the other is enterprise fit; and then we use the matrixes – the result is displayed as a bubble chart, so the size of the bubble is the marketing, so those are the three dimensions.  And I cover the software lifecycle management at Ovum, and we published three Ovum decision matrices covering the whole life cycle, so one was on application lifecycle management, one was on Agile project management, and the other, DevOps release management.

    Alan Shimel:                Fantastic –

    Michael Azoff:             The ALM – sorry, do you wanna ask a question?

    Alan Shimel:                No, no, I said that’s fantastic.

    Michael Azoff:             Yeah.  It’s not common for us to – for one analyst to do three at the same time – I think I’m the first to do that – but it made logical sense because I’m covering the lifecycle from end to end.  The ALM one we’ve been – we’ve had a cycle of these decision matrices for many years, but this is the first one that spans not just enterprise IT but also engineering manufacturing, where, because of the exponential rise of software content in advanced products, there is a very, very clear need for managing that complexity and a role for ALM.  So this covered, for the first time, the engineering side as well.

    The Agile project management was then a subset of the ALM one and focused purely on enterprise IT, so that’s the original scope for ALM.  Calling it “Agile project management” because it’s very much about the management at a high level, and then using – typically, organizations use a lot of open source tools for code development, so that made logical sense to name it in that fashion, with Agile being now so typical and common, but many of these solutions are generic and allow any kind of process to, from traditional stage-gates through to Agile, allow that coverage.

    And then DevOps release management, which has been around for some time – I think the first report where we looked at products was in 2010, but, this year, we’re seeing the topic has become really, really hot, and it was timely to do an Ovum decision matrix – in fact, the first proper decision matrix on solutions in that sphere.

    Alan Shimel:                Got it.  Let’s talk about some of the companies and what – well, before we do that, Michael, can you give our listeners a little insight into how this was conducted?

    Michael Azoff:             Sure.  So the original matrix terminology, I think, stemmed from the fact that we send the vendors – we invite vendors to participate.  We send them project criteria.  If they fit the criteria, then they’re in.  It’s, essentially, we’re looking at the top players in the market.  I also tend to invite some of the more interesting and innovative smaller companies to participate as well because I think that that’s of interest to the readers.  But, generally, it is the top market leaders who are participants.  So we send them a spreadsheet and that’s their sort of matrix.  It’s – has the 200 to 400, which we’re actually trying to reduce the number of questions, rows, that we have in the matrix, but the vendors fill these out.  We then have a briefing with the vendors.  We have a demo of their product, and we also delve into their marketing approach and we look at their financial numbers.  We look at their approach to customer service.  So it’s very in depth, it’s multi-dimensional, as I mentioned, and, on that basis, we then produce the decision matrix bubble chart.

    Alan Shimel:                Got it.  I don’t know if we wanna name names, Michael, but let’s take the DevOps matrix, to start with.  What were – who – according to the matrix, what were some of the let’s call it “top performers” – is that a good term to use?

    Michael Azoff:             Yeah, it certainly is.  And I think of all the – I’ve been an analyst since 2003 and conducted these type of vendor product comparisons, and I would say this has been the most contentious and the most difficult to, of all of these exercises, in drawing vendors apart.  So I ended up with quite a number of leaders who looked very sort of in that leading category.  Oh, I can – I’ll try and do this alphabetically, so, let’s see, so CA, CloudBees, Automic, Clarive, Microsoft Electric Cloud, IBM, Serena – did I mention CA? –  XebiaLabs, so, yeah.

    Alan Shimel:                Sounds pretty comprehensive.

    Michael Azoff:             [Chuckles] There’re a lot of vendors.  They all did extraordinarily well.  It was very difficult to draw them apart, but they all have rather different approaches to the market, and this is what is sort of delved into in the actual ODM report, so I do encourage people to actually look at the report and read carefully as what – so that’s a strength, weaknesses, opportunities, and threats analysis, which goes into quite a lot of detail and really gives the flavor of each of these solutions, in that leading category.  And then we have some challenger solutions as well, yeah.

    Alan Shimel:                Got it.  And, Michael, I mean, certainly DevOps is on top of everyone’s list of hot topics or near the top of everyone’s list of hot topics.  You know, separating the hype from the reality here, just where’s the ceiling for these things?  I mean, do you see – what do you see down the road in short term – 12 months, 18 months, 24 months?

    Michael Azoff:             Well, we had the first wave of the innovation in this market with support for managing continuous delivery, so, at an open source level, there was activity.  There were vendor startups that provided their own continuous delivery solutions and then, on top of that, management and orchestration.  So all of that was happening around 2011, and the larger vendors made acquisitions.  I mean, IBM acquired UrbanCode; CA acquired Nolio; BMC, StreamStep.  So very much a sort of rationalization and an anticipation of the market.  But we’re still seeing new players come onto the scene, like Clarive, for example, is an interesting one and CloudBees, the open source project – owners of Jenkins have sort of stepped into the enterprise side and expanded their offering with an enterprise-ready release management solution – so still a lot of activity.  And I would say the next step in this market would be ALM and release management tying a lot closer, and I think, from a customer point of view, it would be a useful benefit to have a single ALM solution that included these advanced release management technology in there as well.

    Alan Shimel:                Yeah.  Absolutely.  Michael, where do you see – now one of the questions I always get is, with all due respect, right, these analysts do great reports, but they’re behind firewalls, they’re behind reg-walls.  One of the nice things about these Ovum matrices is I see IBM and some of the other vendors are making the matrices themselves available if you’re willing to fill out their registration form, and what I like about that is it gets this intelligence into the hands of people, whether you wanna take it slanted or whatever because you had to fill out a registration form – that’s up to you – but for people, Michael, who are saying, “How independent – how much stock do we put in these things?”  You’ve already given us a little background into the methodology behind the research, the wide spectrum of companies you’re covering, but talk about independence of Ovum and of your research here, so – I want people to understand that.

    Michael Azoff:             Yeah, absolutely.  So, as analysts, our credibility is our independence, so we’re not aligned with any vendor.  As an analyst firm, we face both ways – we do work for vendors, we work also with end-user customers, and we also provider solutions for vendors and for enterprise customers.  So we face both ways – we work with all parties – but our independence is our credibility in the market, so we take a completely objective view of the responses from the vendor.  And, sometimes, the vendors don’t like what they see, but they actually find it very useful to get a completely unjaundiced and independent view because it helps them understand exactly where they are in the market.

    I think the ALM one, in particular, was a bit of a shock for a number of vendors because of our re-scoping of how we look at ALM.  Some vendors completely ignore the engineering market, and we see that as one of the growth areas in ALM, so I think that caught out a number of vendors by surprise, despite the fact that we’ve been telling them they ought to look at that part of the market, for ALM.

    Alan Shimel:                Absolutely.  Michael, can you give our readers what’s next?  What other matrices related to these subjects or other kind of research might you guys be working on next?

    Michael Azoff:             Sure, sure.  So, personally, so my brief is the software development lifecycle management, and I cycle through three areas – ALM, mobile development platforms, and application performance management – despite the fact that the ALM one was a triplet, but it is, logically, the lifecycle, if you like.  So the next one in the cycle will be Q4 this year, and that’ll be on application performance management.

    Alan Shimel:                Great.  All right.  Michael, we’re just about out of time, unfortunately.  I apologize; maybe we can talk again another time.  It was great chatting with you and I hope our readers have learned something here that can help them.  And thank you for all the research you do – can never have enough information on this stuff.  Micheal Azoff, principal analyst at Ovum, thank you very much.

    Michael Azoff:             Thanks, Alan, for inviting me.

    Alan Shimel:                Thank you, and this is Alan Shimel for devopsy.kinsta.cloud.

  • Container Usage and Adoption, Here is Your Chance to Tell Us What You Think

    Container Usage and Adoption, Here is Your Chance to Tell Us What You Think

    We are teaming up once again with ClusterHQ for an update on Container usage and adoption. Our new survey is available and shouldn’t take more than 5-7 minutes of your time. We are looking to see if the container adoption and usage has changed since our last survey last summer. Please take a moment to fill out the survey. If you fill out contact info at the end, you are eligible to win a $50 dollar Amazon gift card. One in 50 wins a card. If you don’t want to give any contact information, you don’t have to but we can’t contact you if you were to win a gift card. Either way we would love your input!

    While containers are capturing lots of buzz and attention, many still doubt their impact in real world procurements. However, we are hearing enough subjective feedback to think that this is not the case. We think containers are catching on quickly, perhaps even quicker than cloud adoption did at similar time frames. But that is subjective. We are looking for numbers that prove or disprove it. So even if you are not using containers now, we want to know that too.

    The standard line is that containers are being tested in dev and test environments, but are not ready for prime time. Yet Docker, CoreOS, Kubernetes and the entire container ecosystem point to more and more customer references. Can everyone be just playing with containers in their labs? We don’t think so.

    On the other hand, there are questions about security, scalability, networking. Should you lock in to one vendors complete stack? How open should the ecosystem be? What about data, databases, OS, etc. Lots of questions and we really don’t have a lot of objective data points. Help us change this by giving us your own thoughts, experiences and ideas.

    We will share the full report with analysis with our readers when complete. But don’t miss this chance to be heard and make a difference.

  • The DevOps Institute, What a Difference a Year Makes

    The DevOps Institute, What a Difference a Year Makes

    It was just about a year ago that we announced the formation of the DevOps Institute (DOI) here on devopsy.kinsta.cloud. Wow, what a difference a year makes! Some folks thought that formal training and testing for DevOps knowledge was sacrilegious, others thought it a joke, others that it was pre-mature. But here we are a year later and the idea of DevOps training seems to have taken root. So much so that even some of the old warlords of the traditional IT training space are trying to muscle their way into DevOps training as well.

    We are launching a DOI neighborhood here on devopsy.kinsta.cloud to feature content related to DevOps training, the DevOps Institute, their partners, reps and students. We welcome your input. If you would like to contribute you can write me at editor@devops.com.

    I wanted to take a moment though and return to this past year and the state of DevOps training. I think much of the initial resistance we encountered in some quarters was to the idea of certifications of DevOps training. In fact, I would say much of it was resistance to the idea of certification in IT period. Over time the market and certainly we here at the DevOps Institute realized that while certification is something that is important for some employers or career paths, it shouldn’t take away from the real aim of the DOI’s mission.

    The DOI’s mission is to gather information, evangelize and educate the market about the emerging practices in DevOps. Notice I did not say best practices. This is because we believe that we have not had really recognized or perfected best practices. We are seeing emerging practices and watching closely to see which ones continue to emerge and offer the best state-of-the-art in DevOps training and education.

    In the meantime, we are seeing DevOps training offerings coming out of the woodwork. Many of the tools vendors are developing and putting out training and certification specific to their tools. I think this is essential for employers to be confident that an employee has the expertise with a given tool set.  Practitioners are going to want this training and certification to prove their proficiency on a given tool. I would like to see us incorporate some of these tool classes as part of the DOI offerings in the coming months.

    Some of the traditional IT training folks are taking matters into their own hands and developing one-off DevOps classes. As with everything else, some are better than others. In digging in you will find some are a quick money grab and some are actually pretty good.

    As I mentioned earlier, some of the older stakeholders behind ITSM, ITIL and Scrum training are trying to jump on the DevOps bandwagon. They promise openness, but their business models are all but open for the most part. There is more to DevOps training then putting logos on a website. In the meantime, one thing we have learned for sure is lets not repeat the mistakes of the past with some other types of IT training.

    The IT industry and IT training are well evolved global industries. It is a for profit industry obviously. My advice is, buyer beware, your mileage may vary when choosing a DevOps training provider.  DevOps is not ITIL, not ITSM and while Agile is tangential, it is not exactly the same either. In fact while Scrum Agile training is pretty well developed, it is not the same as DevOps training per se. Their are Agile methods and lessons that DevOps classes can take, especially the DevOps for Ops type of classes. But lumping DevOps and Agile together is not the right path either.

    At the DevOps Institute we have a world-wide network of registered education partners who are offering our tried and vetted DevOps Foundation class, as well as our other two classes. If testing and certification are important to you, our global partner PeopleCert will administer and deliver it for you.

    We are also hard at work to deliver the next generation of DevOps training classes. I don’t want to talk out of school, but we have spent the last year listening to the hundreds of people who have taken our classes, our partners, speaking with the leading lights in the DevOps world, I think what we have in store will once again set the bar in DevOps training and education.

    In the meantime, check here at the DOI neighborhood often. There will be a steady stream of good content related to DevOps education from many different sources. You may just learn something 😉

    Indeed the first year of the DOI has been quite a ride, but buckle in because things are really going to pick up now.

  • DevOps Chat: Threat Stack’s Pete Cheslock and Chris Gervais

    DevOps Chat: Threat Stack’s Pete Cheslock and Chris Gervais

    I recently had a chance to sit down with Pete Cheslock and Chris Gervais of Threat Stack to talk DevOps and Security. Both of these guys are dialed in on both topics so as you can imagine it was a great conversation.  Here is the audio file with the transcript underneath.

     

    petechesPete Cheslock, Senior Director of Ops and Support – As the head of Threat Stack’s operations and support teams, Pete is focused on delivering the highest level of service, reliability, and customer satisfaction to Threat Stacks growing user base. An industry veteran with over 15 years’ experience in DevOps, Pete understands the challenges and and issues faced by security, development and operations professionals everyday and how we can help. Prior to Threat Stack, Pete held senior positions at Dyn and Sonian where he built, managed and developed automation and release engineering teams and projects.

     

    chris gerChris Gervais, VP, Engineering – As Threat Stack’s head of Engineering, Chris is passionate about building, not only a rock solid, high-performance product, but also a team of elite engineers, industry best processes and a culture that attracts the best talent. Prior to Threat Stack, Chris held senior positions at lifeIMAGE, Enservio, Partners Healthcare, Inc., Inflexxion, Inc. and VIS Corporation, where he was responsible for engineering, technical operations, and technology strategy for cloud platforms.

     

    Alan:                              Hi, this is Alan Shimel from devopsy.kinsta.cloud for another DevOps chat. Happy to be joined today by two special guests, both                                               from Threat Stack. First is a gentleman pretty well known within the dev ops and security space, Pete Cheslock. Pete,                                                      welcome.

    Pete:                             Yeah. Thanks for having me.

    Alan:                             Thank you. And joining Pete and I is, he’s kind of Pete’s partner in crime here, Chris Gervais. Chris, welcome.

    Chris:                           Thanks so much.

    Alan:                             Great. That was our audio check, guys, and we’re good. So Pete and Chris, why don’t – our audience may not be familiar with Threat Stack. Can you give briefly a little background on the company?

    Pete:                             Yeah. Absolutely. So Threat Stack is a company that’s been around for a few years now, and what we’re doing is we have a cloud security platform that is basically designed to work with all kinds of different workloads that are running, whether in the cloud or in your own data center, to analyze for internal/external threat, to analyze for data loss prevention, or – and basically just auditing the kind of, answering the question of who did what when on your system.

    So if you’re someone who is on a security team and you need to follow various auditing rules, PCI, or HIPAA, or things like that, you can use Threat Stack to basically comply with those policies. And also if you’re just an operations team and just trying to understand, you’re doing, kind of doing the dev ops. You’re giving people broader access to your systems a you’re trying to understand what they’re doing with that access, trust but verify, you can use Threat Stack to basically determine and answer those questions for you.

    Alan:                             Fantastic. And Pete, is this delivered as a service, or is it – not an appliance any more, but and not even a on prem. But is it a service?

    Pete:                             Yep. It’s a SaaS app. We have a very lightweight agent that runs on the system, and what we do is right now we support Linux systems. We’re capturing events from the Linux kernel, so it’s that source of truth of all activity on a system. And we also do some integration with if you’re on Amazon we do some integration with the cloud trail so that we can alert on not only your system-level events, but also for Amazon users to _____ on cloud trail events, so events that are happening at a higher kind of EPI level.

    Alan:                             Great. And guys, I don’t – I didn’t mention your titles. I apologize. Chris, what’s your role at Threat Stack?

    Chris:                           So I’m the VP of engineering here.

    Alan:                             Okay. Excellent. And Peter?

    Pete:                             So, I run the operations and support teams, the technical operations.

    Alan:                             So we’ve got tech ops and engineering? Excellent. So guys, and we were talking a little bit before we started the recording here about this whole – the evolution, if you will, of security, you know, security tribe merging or at least joining into this larger dev ops tribe, if you will. I don’t know if it’s larger. But the merger of security and dev ops. Chris, I know this is something that you followed now for a few years. What’s kind of your take on it?

    Chris:                           You know, I think it’s, like there’s a couple things here, one of which is, especially for folks who are building in the cloud and trying to take advantage of all of the sort of speed and velocity you can get with software to find everything and all that stuff is you can’t adhere to the model the security is the domain of the few any more, and that it’s a walled-off thing over in the corner, or that it lords over your software development engineering process, roll-out process, infrastructure process.

    Like, all that stuff has to get baked in, right? And it has to get baked in at the earliest possible point that it can. And one of the best ways to do this, and it’s a thing we’ve done at Threat Stack is, it’s not just about the tools. It’s about making sure that your entire team is involved with this from the start, and that it’s not just a person who’s got to sit there and be a gateway and a worrier about this, but everybody is focused on it, right?

    Just like today, you’ve got, whether you’re a software engineer or infrastructure engineer, you’re an engineer. You’re sitting together, and you’re solving problems together of how do I get my stuff out? What kind of systems do we need? What do my work loads look like? You’ve got to take that same approach with security and make it just part of that flow. And so in some ways, like if you think about the democratization of this stuff, it’s really about – and this is one of the things behind Threat Stack is make this inclusive, not exclusive, because you can solve problems better that way.

    Alan:                             Amen. Pete, you and I first met, I think it was shortly before I even launched devopsy.kinsta.cloud. And so I know you’ve dealt with this and have been dealing with this issue for years. My impression in speaking to a lot of people is that the developer and even ops community seems much more open, if you will, to welcoming the security folks into the meeting, into the tribe, and giving them the seat at the table. Where too often I’m afraid to say, because I come from the security side of the house, it’s the security guy who’s digging in his heels and saying, “No. We can’t have that. We need to maintain control. We need to maintain independence. We need to have our own kind of thing.” But the good news is I see that kind of hard headedness softening and I do see us, the security folks coming in. What’s your impression?

    Pete:                             Yes. I remember. We were actually doing a – it was like a kind of roundtable dev ops discussion, and what I thought was most interesting is a lot of the _____ were all tilting more towards the security side. And yeah, that was a couple years ago at this point. Yeah. So I definitely agree. The conversation that I see in attending a lot of the different kind of web operations and dev ops related conferences is much more on the side of operators and developers who have essentially kind of figured out how to work well together and deliver value for businesses are realizing that security is much more important than it ever was.

    The kind of joke is it was always important. It’s just a lot of people just didn’t really care about it. But now it’s affecting so much of what we’re doing and more and more issues and vulnerabilities and open-source software are kind of coming to light that I think more operations and dev teams are realizing that this is something that we really need to deal with now versus having some sort of company-ending event. And so I think what’s happening is that especially smaller start-up companies, even companies that get up into a few hundred engineers don’t even have a dedicated security team, so they kind of have to do it themselves.

    In more legacy teams, I see it as well where they want to, more legacy companies, they want to build _____ they bring in security engineers for that organization. And you find a lot of the same thing where, like you were saying is, they want to slow things down and they want the control. The problem is is that that model doesn’t work any more. And we’ve seen it. It’s the concept of shadow IT, right? The security team up there constantly saying, “Nope. Can’t use Amazon,” because of whatever reason. It doesn’t stop anything. The company will end up having ten Amazon accounts under ten corporate credit cards.

    Chris:                           Yeah. That’s such a good point, too, because I think one of the things, like the fundamental shifts you have to make is, right, a lot of that old security thinking was rooted in prevention, right? And so if you really think that you can use that model in sort of the modern era, God bless ya. But, man, that’s going to be tough. Versus if you can now focus on detection and involvement, you’re going to be – and then, right, you’re dev opsing the things because you want to go fast. You can now put changes into effect super fast by connecting your information sources to the things that allow you to take, allow you to make change quickly. That’s how you get – I think you really make some progress. And that’s where we see a lot of folks fall down when they think they can take the sort of legacy enterprise IT approach and just bring that to the cloud, including the type of people that are involved.

    Alan:                             Absolutely. So, guys, let me bring this back to Threat Stack, if I can for a moment. Your customers, you think they come from the dev and sys admin or ops space? Or are the security people your customer, as well?

    Chris:                           It’s both, and as our company’s grown and as our customer base had grown and we go up market more, we’ll start having more and more folks who have info sec and other titles like that in discussions with us. Where we kind of started was with the dev ops community, right? We’re a very dev ops friendly tool in terms of getting our agent deployed. And like Pete did an awesome job of building cookbooks and templates that people could use to get Threat Stack running really quickly so that it wasn’t a pain in the ass to get started. It was really, really simple. But that is going to sort of start to change over time, but what we hope is that we’ll continue to see the folks who are dev opsing and infrastructuring involved in that conversation and it doesn’t just turn into the domain of just the security people.

    Pete:                             Yeah. In a lot of cases, too, what happens is you have a CTO or a head of engineering for some company, and maybe they’re running 200, 300, 400 servers on Amazon. Not trivial number of systems, but still not kind of enterprise scale of thousands of systems. But they’ll have their head of engineering come to them and say, “We’re about to close this deal. It’s with this company. They are going to require us to get our PCI compliance, or HIPAA compliance,” or some sort of audit _____. And so as an operations person, I’ve been in this scenario before at a previous company. I was running an operations team and we were about to sell it to the US government, which required us to go through a thisba audit, which was very intensive audit. And this was years ago, and we ended up having to build a lot of the tools. And I always kind of joke here. It’s like I love working at Threat Stack in operations because I get to use Threat Stack on my platform that I run. It’s awesome that way.

    Chris:                           I have to go build tools like I used to.

    Alan:                             Yeah.

    Alan:                             Exactly.

    Chris:                           Yeah. And to that point, it’s actually one of the reasons why I joined Threat Stack was that in previous roles where I delivered – my teams delivered – stuff into health care and other regulated industries and something like Threat Stack didn’t exist, so I had to stitch together stuff painfully from other types of tools to answer like all these security requirements being dumped on my desk from larger enterprises who weren’t used to dealing with sass companies. And thrown into the world of print security. And having a tool for me like Threat Stack, and frankly getting the opportunity to help build it out, was such a huge opportunity and attractive for me to come here because you could just instantly see the problem that this was going to solve.

    Alan:                             Absolutely. So, guys, we’re running low on time because these things always go quickly – too quickly. But I’m doing a webinar next month with a couple of companies called New Frontiers in Cloud Security. I’m going to ask each of you, what do you see as sort of the biggest new threat, if you will, on the horizon for cloud security?

    Pete:                             Yeah. That’s a really good question. I think what we’re finding is that as people move to the cloud, there was a long time a lot of thud around the cloud is not secure. You can’t move to the cloud. It’s not secure. And in reality, the cloud is just as or can be more secure than your existing environment if you use kind of the right tools to manage and monitor the systems, especially for Amazon users. They have a whole suite of tools that can really assist you to secure your system well.

    What I regret it’s, and especially as someone who runs an operations team for a security company, we do everything we can to lock down the front door, to make sure that it is extremely hard to get onto systems to do things. Like we have a lot of checks and balances in order to do so. But honestly the biggest fear I have is people coming in from the back door, essentially, and trying to get in through some sort of malware on their systems, or through some sort of fundamental breakage in an open-source code where like Heartley had happen last year.

    Alan:                             Yeah.

    Pete:                             So that’s where I’m glad to have tools here via Threat Stack and other tools that we have that I can continually monitor my systems for these anomalies. Because it’s going to be nearly impossible to know of what the next zero day kind of critical bug is. But if I can monitor for anomalous activity, that can give me a heads up in advance.

    Chris:                           Right.

    Alan:                             Perfect. Chris, how about you?

    Chris:                           So, I think one of the biggest threats, actually, is, and just adding to what Pete said, is people thinking they can solve cloud security like they solve on-prem security. And I can just worry about things at the ingress and egress point of my network. And I used this appliance thing at my last place that had, you know, it was co-load or my own data center, and I just want to replicate that model in the cloud, right?

    Which, I just think is – you have to look at the work load and the host as that’s the, right, that’s the battle ground, and if you’re thinking you can solve this at a network layer, it’s going to be really tough because that doesn’t tell you what’s happening on your systems, which is, again, these things are coming and going, right? You’ve got probably more cattle than pets. You’re able to build up and burn down really quickly.

    Are you able to really identify what was anomalous on those work loads over time? And if you can and if you think you can just solve it like you solved stuff five, ten years ago, it’s just like a rude surprise. To me, that’s one of the biggest threats out there.

    Alan:                             I don’t disagree, guys. Hey, I’d love to sit and chat all day, and maybe we will in the future. We’ll get together at some dev ops days or something. But I’m going to need to wrap up here. We’re kind of at the end of our time limit. So Pete Cheslock, Chris Gervais, Threat Stack. Thank you so much for appearing in this segment of DevOps chat, and we’re looking forward to hearing more about Threat Stack and dev ops and security working together to make the cloud better for everyone, and continued success.

  • Puppet, Like DevOps, Continues to Mature

    Puppet, Like DevOps, Continues to Mature

    Over the course of the last several years we have seen the DevOps movement continue to mature and evolve. It has moved beyond the early adopter, visionary stage into the mainstream of the market. Therefore, it should be no surprise that some of the leading solutions in the DevOps space should likewise mature and evolve as well.  Yesterday Puppet (formerly Puppet Labs) made several announcements as part of a broader message that they are ready, willing and able to continue to be a leader in this space for years to come.

    There are several parts of the Puppet announcement yesterday, lets have a look at each of them:

    Growth indicators – Somewhat mandatory, Puppet announced that they continue to enjoy rapid growth. puppet growth

     

     

     

     

     

    Not a lot to add here, the numbers speak for themselves.

    Puppet Labs is now just Puppet. In my conversation with Nathan Rawlins, SVP of marketing, he said that this was a case of recognizing what the market is already doing.  I don’t know how many people you have heard refer to the company as Puppet Labs. Most everyone I know says Puppet. So why push rope up hill? Henceforth the company will be known simply as Puppet.

    puppet

    But there is more than just the name here.  Rawlins told me that along with the new name, they have also gone through a complete rebranding. New logo, new website look, new collateral look. The new brand seeks to give the impression of simplicity, stability and maturity.

    sanjayNew leadership – The company has hired a software/tech industry veteran leader, Sanjay Mirchandani as President, COO. Mirchandani has held senior leadership roles at VMware, EMC and Microsoft. His responsibilities will include go-to-market operations, including sales, marketing, customer success, and global expansion. From what Rawlins told me, Sanjay will be leading much of the day to day operations of the company.

    This is not a case though of a professional leader coming in to replace the founder/CEO.  Puppet’s Luke Kanies remains in the CEO role. Mirchandani will free up Kanies to do what he is best at. Be a visionary and chart the course for Puppet and in turn help shape the DevOps and software delivery market as well.  It takes a confident founder to bring in a real professional to help run the business to allow you to do what you do best. Many are too insecure to share management with a newcomer who “just wouldn’t love their baby the way they do.” Kudos to Luke for recognizing this move for the long term good of the company.

    blueshift by puppetProject Blueshift– Many people are focusing on Blueshift’s capabilities of using Puppet with container technologies like Docker, Kubernetes, Meseosphere, CoreOS, etc.  While Blueshift does focus on this as of the release today, there is actually more to it than that. Blueshift is really a collaboration between the Puppet community and the company itself to ensure that Puppet will always be able to help companies adopt next-generation infrastructure technologies. While today those next-gen technologies are container related, the idea is to grow Blueshift into something capable of working with new technologies as they emerge. It is a longer range project beyond 2-3 years, instead looking at what could be on the horizon 5-10 years from now. It is an ambitious vision. It is always hard to know what is the next big thing. But the fact that Puppet is even attempting to keep its eye on this is commendable.

    Upgrades to Puppet Enterprise and Puppet Orchestrator – Mixed in all of the news is that Puppet has released upgrades to its Enterprise product and the Orchestrator product that was released last year. Without going into a feature by feature recap (you can read the link to the PR if you like), Puppet continues to polish their enterprise products as part of their maturation.

    Integrations with Splunk and HipChat – As DevOps matures, the market will want greater integration between their tools. Puppet has taken a nice step in that direction by releasing a Splunk App that will allow you to automate set up of Splunk servers and give greater visibility into enterprise DevOps environments.

    The HipChat integration allows your Puppet Orchestration management to show up right in the HipChat GUI and allows users to manage it from within HipChat. A nice bonus is the access rights which make sure that those without permission do not have access to the Puppet Orchestration data.

    All in all, this is a major step up by Puppet. To be fair, the folks at Chef have also been taking steps to further mature their product and organization. As DevOps continues to grow, I am sure we will see some of the other DevOps tools startups follow the leaders here in maturing and growing along with the DevOps market.