devopsy.kinsta.cloud

Author: Alan Shimel

  • Jenkins World Speaker Gruver on the State of DevOps

    Jenkins World Speaker Gruver on the State of DevOps

    Santa Clara, California, will be home to the biggest gathering of Jenkins users in the world Sept. 13-15. This year’s Jenkins World conference will feature Gary Gruver, DevOps expert and author of “Leading the Transformation.” We had a chance to connect with Gary and hear his thoughts on the state of DevOps, continuous delivery and what he thinks the biggest trends are.

    devopsy.kinsta.cloud: As continuous delivery (CD) and DevOps continue to be adopted and advance, what specifically should we be on the lookout for?

    Gruver: I believe the biggest opportunity for breakthroughs in CD and DevOps is in large, complex, tightly coupled systems. Most DevOps implementations have been with smaller teams—whether in small businesses or large businesses—that allow these small teams to work fairly independently. Currently, these are the fastest moving, most innovative DevOps implementations. That said, I feel the biggest opportunities for positive business impact are in the larger, more complex systems just because they are currently much less efficient. This is why I think we will see the biggest improvements in those environments, and innovations and updates will track towards these advancements.

     devopsy.kinsta.cloud: How are technologies like containers becoming a bigger part of an automated pipeline?

    garygruverGruver: Containers make it easier and less complex to move to infrastructure-as-code, which is one of the big breakthroughs of DevOps. This space is moving quickly because of how important environment consistency is to companies. It will be interesting to see how this space evolves over the next few years.

     devopsy.kinsta.cloud: What advice do you have for enterprises just starting their DevOps journey?

    Gruver: Segment the applications down into different deployment pipelines to make the problem as small and less complex as possible. A deployment pipeline should include all the applications that have to be qualified and deployed together because of their architectural coupling. Then, optimize each deployment separately based on DevOps principles instead of forcing everyone to implement all the same DevOps rituals like was common with previous agile transformations. This is a topic I can spend quite a bit of time discussing and thinking about, as you can read more about in my book!

    devopsy.kinsta.cloud: What roadblocks still exist for companies trying to adopt DevOps?

    Gruver: Finding executives that are willing to engage with their organizations and lead the DevOps transformation is a solid roadblock. It is still new concept in larger enterprises that require the multiple acceptance from members of the C-suite.

    devopsy.kinsta.cloud: What do you find most exciting about the current state of CD?

    Gruver: It is finally scaling to large organizations where the majority of the code that is being worked with exists and therein are the biggest opportunities I see for improvement. This means that DevOps is being introduced right up the chain, extending it from just the realm of IT.

    devopsy.kinsta.cloud: What do you want Jenkins World attendees to know about your keynote?

    Gruver: I am planning to provide a framework you can use to help align your large organization on your DevOps journey. My objective is for DevOps practitioners in organizations of all sizes to walk away with tips for implementation and a better understanding of best practices to apply to individual DevOps journeys.

    devopsy.kinsta.cloud: What does being “all-in” on DevOps mean to you?

    Gruver: To me, being “all-in” on DevOps means that everyone one is committed to the DevOps principles and is working together to continually improve the development and delivery processes. In other words, they have the same approach to achieving the same goal.

    devopsy.kinsta.cloud: Where do you think DevOps adoption is today?

    Gruver: Mature in unicorns and just getting started in large enterprises; hence, there are so many opportunities!

    To learn more about Gary Gruver and his approach to DevOps, please visit his homepage. While you’re at it, download a sample of his latest book, “Leading the Transformation.” Interested in learning more about Jenkins World or attending this year’s Jenkins World? Click here and register with the code JWDEVOPSCUST to receive a 20 percent discount.

  • DevOps Chat: Steve Hazel, Sauce Labs

    DevOps Chat: Steve Hazel, Sauce Labs

    I recently had the chance to sit down and speak with Steve Hazel, CTO and co-founder of Sauce Labs. With so much being written and talked about the role of quality assurance (QA) and testing in a continuous integration/continuous delivery (CI/CD) world, it is good to hear from someone like Steve who is an actual thought leader in the space. Steve tells us what he thinks the limits of automated testing are, the future of QA and more. Have a listen for yourself to find out, or follow along with the printed transcript below!

     

    Alan Shimel: Hi, everyone. Alan Shimel, devopsy.kinsta.cloud here, for another DevOps Chat. Today’s DevOps Chat’s guest—that was a tough one—is Steven Hazel, co-founder, CTO at Sauce Labs. Steven, welcome to DevOps chat.

    Steve Hazel: Hi, Alan. Glad to be here.

    Shimel: Thank you. Glad to have you here, actually. So Steven, there might be some people listening who maybe aren’t familiar with Sauce Labs. So, before we start, why don’t we, if you don’t mind, give our listeners a quick overview? Tell us about Sauce Labs.

    Hazel: Yes. At Sauce Labs, we do automated testing for both web and mobile apps. We run a cloud service that gives our customers access to a wide range of platforms, whether that’s operating systems and browsers for web testing, or mobile devices and emulators and simulators for mobile testing. You can get access to all the different platforms you need to test on, and you can get access to a lot of platforms at once to run your tests in parallel to get through a large test suite rapidly, which is really what people need for today’s continuous integration and continuous delivery workflows.

    Shimel: Got it. Of course, Steven, Sauce Labs was closely linked with around Selenium and some of the open-source testing tools that are out there today, right?

    Hazel: That’s right. Selenium is the dominant web-testing technology. In mobile testing, there’s a variety of technologies, but we support Appium, which also uses the web driver protocol that underlies Selenium. We really think that fitting in with those open-source tools is the smart way to go. It fits with what people are doing.

    It gives people a lot of choices about how they want to do their testing, what kind of languages and frameworks they want to use on their end. So, we just plug right into Selenium tests, if you’ve already got Selenium tests, or Appium tests. You can just change the config and point them at Sauce Labs, and they’ll run unmodified on our systems.

    Shimel: Got it. Steven, we were talking before we started recording today, I was telling you about a recent article we had over on devopsy.kinsta.cloud. The gist of it was basically that DevOps was the death knell for QA. I told you I didn’t agree with that and you agreed with me. You said you didn’t agree with it, either. But for our audience—they’ll respect you a lot more than they respect me—why don’t you agree with that, Steven?

    Hazel: Yeah. I think that to suggest that there’s no longer a role for manual QA when you take on a DevOps process is just not in line with the facts. If you look at what we see large organizations doing, they’re not dropping manual QA for automation. They’re changing the mixture of what they have manual testers doing by quite a lot, but they still have manual testing teams. You still need a manual testing team.

    So, what I see happening, as you start to take on automation, your testing coverage improves dramatically because you can afford to do a lot more testing when you’re automating than was ever possible with a manual testing team. But automated testing, the classic example is exploratory testing. You’re just not gonna get the kind of creative, exploratory walk-through of your app with an automated test that a manual tester can do. I think there’s still a role for QA organizations, beyond just manual testing, in being the other side of the conversation, right?

    A lot of people have the concern that if developers are writing tests, it’s the inmates running the asylum. The exact developers writing the software are the ones deciding whether it’s high quality, and you want another perspective in there. You want a perspective that’s maybe closer to your end user. So, I think that the other side, beyond just manual testing, that you see with QA teams continuing to have a role is in deciding what cases should be tested, whether you have good test coverage, encouraging good testing practices, even when you are automating your tests.

    Shimel: Absolutely. Really, Steven, I guess the boogeyman in the room around the friction with DevOps and QA is automation. There’s some schools of thought that says, “Well, we can automate everything. The more we automate, the better we are.” There’s another school of thought that says, “Well, you can automate as much as you can and automation’s not a bad thing, but there are just gonna be some things that are not automatable, if that’s a word now, or may never be automated. Where do you go in on that continuum?

    Hazel: Well, being someone who’s pushing forward automated testing, I want to see automation go as far as we possibly can. I think that that’s very far. That said, I think that the way the mixture of tests changes as you adopt automation is maybe a little bit counterintuitive. You might imagine, well, we’ll automate some percentage of our manual test cases, maybe 80 percent or 90 percent. Maybe we could get to 100 percent if you’re a zealot for automation.

    But actually, what you see is, it’s not that you’re automating a percentage of what was there in manual testing. You’ll actually have more automated test cases than you were able to do with manual testing. So, if you just looked at the number of test cases, your automated cases are gonna way outnumber the original count of manual test cases just because you can, right? You can now cover a lot more edge cases, a lot more scenarios because of the power of test automation. So, that’s a real advantage to test automation.

    Shimel: Sure.

    Hazel: At the same time, certainly there are things, visual testing, there’s some interesting approaches out there, but I don’t think we’ve yet seen a way of making sure that the app looks right, especially as it changes. You really need a human being involved when there are deliberate visual changes to make sure that they came out right. I think it’s those things where automation really can’t give you an answer about, does it look right? Does it act in a way that’s gonna be acceptable to somebody?

    I think you still need a human being in there at some point, checking those things, but it’s a different process. It’s no longer this phase gate before every change is released that you used to have. It’s now a process that can be made asynchronous from the bulk of your development and release process.

    Shimel: Absolutely. If you don’t mind, Steven, a little bit of time on, you mentioned a little bit, but what do you think of the kinds of tests that lend themselves well to automation? Certainly, a visual test of an interface, different arts. What are the sweet spots for automated testing?

    Hazel: I think certainly at the bottom of the testing pyramid, unit testing brings tremendous value. It’s something that’s very easy to automate in a way that’s completely deterministic, very fast. Gives you really quick feedback as a developer as you’re making changes to the code on whether you’ve broken something. But the coverage with unit testing, the coverage of functionality that may be important to your end users, it’s really hard to achieve. It’s really hard to achieve good, solid feedback from your unit tests that you haven’t broken anything anywhere.

    Functional testing, the next layer up, which is what really we focus on, gives you that complete end-to-end check. You’re actually testing the features of your product and you’re making sure that end to end, with all the various components involved, they work properly. That’s more of a challenge for automation, but we’re seeing, I think, a majority of development organizations out there seeing success automating functional tests and real value from having that be something where you can run through hundreds of test cases in minutes and get feedback to your team. So, that works quite well for automation.

    I think it’s that next level up, as you start to get into the types of tests where you’re looking at, what’s an acceptable experience for the end user? User acceptance testing as distinguished from functional testing, where you’re really starting to look for, does it look right? Does it act right? Is the response time throughout the entire process acceptable?

    You can zoom in and measure a lot of these things very specifically, but getting the answer to, “Overall, though, was it a good experience?” That’s the kind of thing where it’s really tough to cover that with automation.

    Shimel: Yeah, agreed. Steven, if you don’t mind, I’m an old security guy prior to DevOps. One of the things within the security community that we’ve really pushed around is the idea of automated security testing shifting left in a DevOps environment and allowing security testing to be done in an automated fashion at a CI/CD-type of level. Where do you see that in this whole discussion?

    Hazel: Security testing isn’t what we focus on at Sauce Labs, so –

    Shimel: Right, I know.

    Hazel: I’m not an expert in this, but it is something that I follow and care a lot about. I think I see a lot going on with static analysis, with some of these tools that can help to constrain the types of mistakes that you could have in a program, type systems and things along those lines. I think really that’s very badly needed in making code secure. Some of the issues we’ve seen come up over the last few years, things like Heartbleed, the Glibc bug, really those kinds of things aren’t acceptable, aren’t something that we can continue to have happen, and I think the solution really is fully automated tools, like static analysis tools and type systems, that can lock down the code and just constrain the types of mistakes that could possibly happen.

    Shimel: Sure. You know, Steven, I see it as very analogous to the QA situation, which is I think a lot of security people get very territorial around job security because they’re afraid somehow that doing automated security testing earlier in the process—shifting left, so to speak—is somehow gonna affect their livelihoods, or make them obsolete.

    Hazel: I can see that. We see that among QA folks, for sure. To me, that’s a shortsighted view. If the world is getting more intense security problems, more intense quality problems, we’re shipping more software, you just can’t solve it 100 percent by throwing bodies at the problem. I think that what’s gonna happen is not that those people’s careers are in jeopardy; instead, as a society, we’re just gonna do more and better security and quality testing than we’ve been able to do in the past.

    Shimel: Yeah, agreed. Steven, we’re running a little low on time, so let me get just one or two more questions. Sauce Labs has been, in my opinion anyway, for what it’s worth, somewhat of a DevOps darling in terms of really encompassing—you’re living the DevOps model. You’re working with open-source tools, testing and automation, enabling automation. Sauce Labs is a player in the DevOps ecosystem. Where do you see it going?

    Hazel: Well, toward the enterprise is one big trend we’re seeing. Earlier on in the history of Sauce Labs, a lot of our customers were essentially software companies, companies that their primary focus is technology. Now, a lot of our customers are retailers, financial institutions—companies that you don’t think of as primarily a software company, but all of these companies have apps, they have complex web experiences. They’re really adopting DevOps in a big way. They’re moving to what is, for them, a very different process than what they’ve been doing and allows them to ship better software faster, with more complexity than they were able to handle before.

    Shimel: Absolutely. Steven, we are low on time. I’m gonna ask you the final question, which I ask most all of my guests here on DevOps Chats. That is, if you had to recommend one book to our audience that they should read, a must-read for them, over the next six months or a year, what would that book be?

    Hazel: Oh, wow. A book recommendation. I think the obvious choice in a conversation about DevOps is “The Phoenix Project.” If you haven’t read it, you’ve got to read it. It’s a quick, enjoyable read, but it really gets the concept across better than probably anything else is going to. It’s an obvious recommendation, but I still think it’s worth it.

    Shimel: Sometimes the obvious is good. I will just add to that, if you already have read “The Phoenix Project,” Gene Kim’s next book, I think co-written with John Willis and Jez Humble and someone else that I’m blanking on – oh, darn it, the guy who started DevOps, who coined the phrase. Patrick. Patrick Debois. Their new book, I think it’s called “The DevOps Handbook,” will be out, I want to say, in the fall. Not a sequel to “The Phoenix Project,” but another good book to look at.

    Anyway, Steven Hazel, CTO, co-founder of Sauce Labs, thanks for being this episode’s guest on DevOps Chat, and continued success with Sauce Labs.

    Hazel: Thanks a bunch. Thanks for having me.

  • DevOps Chat: GitHub Enterprise as a Hosted Service, with Jean-Louis Vignaud

    DevOps Chat: GitHub Enterprise as a Hosted Service, with Jean-Louis Vignaud

    I recently sat down with Jean-Louis Vignaud, program manager at IBM, about the new GitHub Enterprise as a hosted service that recently was rolled out on Bluemix. The GitHub Enterprise as a hosted service is a great option for enterprises that, due to compliance or other security requirements, cannot used a shared, public GitHub service.

    This GitHub Enterprise as a hosted service is the first of its type available and is hosted on the Bluemix service as both on-premises and hybrid environments. You can get more info on this at:

    1. Blog : Introducing the first-ever GitHub Enterprise as a hosted service

    2. Video : Benefits of GitHub Enterprise with IBM Bluemix Dedicated

    3. SlideShare: IBM Bluemix Dedicated – GitHub Enterprise

    Also, we will have a webinar that goes into greater detail on this. More info is at: http://webinars.devopsy.kinsta.cloud/scaling-devops-github/

    In the meantime, here is the streaming audio file of this chat, followed below by the transcript of our conversation to follow along.

    Alan Shimel: Hi, this is Alan Shimel, devopsy.kinsta.cloud, and I’m here with another DevOps Chat. Today’s guest on DevOps Chat is Jean-Louis Vignaud, Program Manager from IBM. Jean-Louis, I hope I didn’t mess up that name too bad.

    Jean-Louis Vignaud: No, that’s fine. Thank you, Alan.

    Shimel: Okay. Welcome to DevOps Chat, Jean-Louis, and as I mentioned, you are a Program Manager at IBM, and right now anyway, you’re very involved in working on the GitHub Enterprise as a hosted service offering, and we wanted to talk to you specifically about that.

    Vignaud: Okay.

    Shimel: So, Jean-Louis, I think everyone listening out here is familiar with Git and GitHub, but they may not be familiar with the concept of GitHub Enterprise as a service, so why don’t we start there, if you can explain to our audience a little bit about what that is.

    Vignaud: Okay, so maybe we can start with GitHub first.

    Shimel: Okay.

    Vignaud: GitHub is very well-known, it has probably 15,000,000 users as of today, it’s a very well-known user experience. It’s a collaboration platform, and it’s based on Git, so it’s running on top of Git, but it has many other services on top of Git. And the purpose of GitHub is to provide this collaboration platform that enables people from all around the world to collaborate on a business project, or even a private project.

    And that very well-known collaboration platform is very attractive for enterprises that want to provide the same level of collaboration within their own organization. And so what was introduced by GitHub the end of 2011, early 2012 was GitHub Enterprise. GitHub Enterprise is an on-premises version of GitHub. So, same set of capabilities, but you can install it when it’s on-premises in your—on-premises in your environment, and get it working within your firewall. So that enables teams to—you know, to enable organizations and different teams to collaborate among each other in a safe way.

    So that’s the background, and where we were standing before we introduced our offering.

    Shimel: Mm-hmm, and [Cross talk]—I’m sorry. I didn’t mean to interrupt.

    Vignaud: Yeah, so what I was going to say is that, as usual, inside an organization, as soon as you have to install your product, you have to run it, you have to manage it, you have to provision your infrastructure, you have to have the people set up and standing to manage the GitHub Enterprise offering, meaning doing the backup, doing the upgrade, monitoring its running and doing everything that needs to be done in order to comply with the enterprise security requirements.

    And that requires time, and most of an inside organization, you know, people are looking to move to the cloud, benefit of the cloud facilities, which they could find in GitHub today, but it’s a public cloud that does not meet the security requirements of an organization, and they would want the same GitHub experience, but within their organization. And this is where we come with our service offering around GitHub Enterprise—providing the user experience of GitHub within the organization while still managed by IBM.

    Shimel: Got it. And just to make clear, Jean-Louis, as far as I know, IBM is the only one actually offering this GitHub Enterprise as a hosted service, correct?

    Vignaud: Yes, this is a first-of-its-kind offering. I know if you look into what GitHub provides, GitHub provides GitHub Enterprise so you can run it on premise. You also can install it on infrastructure as a service, so you can run it inside AWS, you can run it inside Azure, but there was no one providing a service offering around GitHub Enterprise. So, with IBM, it’s hosted and managed by IBM so the “and managed” is unique.

    Shimel: Got it. And another thing I just want to emphasize, because as we were speaking about before we started today’s broadcast was, you know, this is in partnership with Git, right?

    Vignaud: Yes, that’s a partnership with GitHub, yes. We announced the partnership at InterConnect early this year in February, and so since the announcement, we have been working and creating this offering. So it took us 12 months to build it and to release it.

    Shimel: Understood. And I think that’s important, because you know, it’s one thing to just take some open-source project and offer it as a hosted service, right? Anyone could do that, it’s open source.

    Vignaud: Yes.

    Shimel: But to really have the cooperation with Git behind this really gives, I think, the best chance for enterprises to have their own Git environment really, truly as a hosted service.

    Jean-Louis, I wanted to talk about another aspect of this offering, and that is, as it’s part of an Integrated Bluemix Dedicated offering as well, right?

    Vignaud: Yes.

    Shimel: So let’s start off with, what is Bluemix Dedicated?

    Vignaud: Okay, so IBM platform-as-a-service offering is Bluemix. So, Bluemix, it consists of a huge set of services, for mobile application, for cognitive applications, so about more than 150 APIs organizations can use to build a cloud-native application, to integrate these applications with a back-end system. And so Bluemix is available in the public cloud, but as well, it’s available as a single-tenant dedicated cloud for the customer.

    So that’s Bluemix Dedicated. So, meaning, it’s a Bluemix for our customer with all this API, all these platforms that enable you to build and run your application. It’s based on Cloud Foundry, it supports containers, Dockers and so on. So it provides a very extensive set of technology that enables organizations to quickly build applications.

    As part of Bluemix, there are a set of DevOps services, so tools we provide to help organizations build those Bluemix applications. And this is where our GitHub Enterprise offering sits. It’s a DevOps offering, part of Bluemix Dedicated.

    Shimel: Got it. So, Jean-Louis, this is—I mean, unfortunately, we only have 12 to 15 minutes here, but there’s a lot of layers that we can peel back it of what one can do with this GitHub Enterprise offering, you know? And especially, in my mind—look, if you’re developing applications and you just want to have your whole platform as a service with best-of-breed stuff such as a Git, such as a Cloud Foundry, all of these elements that give you a best-of-breed application development in platform as a service forum, it seems that all the pieces are here to come together. And it’s a great time to be alive. It’s a great time to have to—you know, if you wanna develop applications, to have that at your fingertips.

    Vignaud: Yes, and in the context of Bluemix Dedicated, single-tenant, completely integrated with your enterprise network, so it enables you to safely integrate with your back-end system. So you really have a very advanced platform enabling you to develop in a safe way; you know, very innovative applications.

    Shimel: Yeah. So, Jean-Louis, two questions for you. No. 1, in terms of advantages of using the GitHub Enterprise hosted versus the public Git, that GitHub that so many of us, I think 50 million is the number of people use—the obvious advantage is, this is a more secure environment, it’s yours only. But are there any downsides? Is there any kind of features not available in the hosted service that would be available in the public service?

    Vignaud: No, not really. You know, the GitHub Enterprise has been designed to provide the same user experience as GitHub. I would say that the value of GitHub Enterprise, it’s the user experience of GitHub, but you can run it for you, so it’s a single-tenant for you as a customer, leveraging the cloud infrastructure from IBM, you can run it in a data center where you want to, geographically you can localize it in the country where you belong. So if you have compliance requirements requiring you to host your source code in-country, you can do that.

    So, I would say, no limitation and much more flexibility when it comes to the deployment of the offering.

    Shimel: Excellent. Next question, I just wanna make sure—is this publicly available today? Because I remember—

    Vignaud: It is, yes. It is available today. We announced it on the 17th of June. We officially announced it on the 17th of June, so yes, it is available today, and any Bluemix Dedicated customers can use it as part of the offering.

    Shimel: Oh, excellent. And I should also mention, Jean-Louis, that in the near future, actually—I think we’re finalizing scheduling right now—we’re actually gonna do a full webinar with GitHub and IBM, where we’re gonna explore a little deeper into this offering and for those of you listening who may be interested, I strongly, strongly encourage you to attend that webinar.

    But Jean-Louis, if people don’t want to wait for the webinar, I know IBM has put up several content pieces where people can get more information from this. One is a blog introducing the GitHub Enterprises service, there’s a video that shows the benefits, and I think there’s also something up on SlideShare about IBM Bluemix Dedicated and GitHub Enterprise. I will try to—

    Vignaud: Yes.

    Shimel: — yes, I will try to include the links to those when we publish this chat, but again, I strongly—if you have questions about his, if you’re a Git user and thinking you’d like your own GitHub Enterprise dedicated service, I’ll try to put those in there.

    You know what, Jean-Louis, unfortunately we’re just about out of time. Is there anything you want to add?

    Vignaud: I think this is fine. Thank you very much, Alan, for the interview here.

    Shimel: Thank you.

    Vignaud: I really look forward to have many customers for this offering.

    Shimel: You know, I think it’s something the market needs. It’s good to have that. As I said, it’s a great time to be a developer today, right? So many tools, so easy to use.

    Vignaud: Yes.

    Shimel: Anyway, Jean-Louis Vignaud, Program Manager at IBM, thanks so much for joining us today, and we look forward to hearing more about GitHub Enterprise as a service.

    This is Alan for devopsy.kinsta.cloud. Thank you for listening in, and we’ll see you on the next DevOps Chat.

    Vignaud: Thank you.

  • From Pockets of DevOps to Dev-Biz-Sec-HR-QA-Sales-Everything-Ops, DOES London 2016

    From Pockets of DevOps to Dev-Biz-Sec-HR-QA-Sales-Everything-Ops, DOES London 2016

    I am just recently back from London (again) where I attended Gene Kim’s DevOps Enterprise Summit London 2016. To me the theme from this years show is that at so many large enterprises (or horses as Gene calls them), we are moving from the initial “pockets of DevOps” trials to full blown DevOps adoption across the enterprise. This DevOps adoption is even moving beyond just the pure Dev and Ops team to include many different parts of the enterprise. Marketing, sales, business units and even HR are jumping the DevOps bandwagon to perform at higher levels.

    Time and time again we saw speakers get up and describe how their organization started with pockets of DevOps adoption 2 to 3 years ago or more and now those successful efforts had been replicated in other parts of the enterprise.The results have convinced other parts of the organization to give DevOps theories a chance.

    Of course not everyone agrees that DevOps has a place in the enterprise beyond Dev and Ops. I spoke briefly to John Willis about it and his initial reaction was that he is more of a purist who believes DevOps is still about Dev and Ops, not HR or other departments. I didn’t get a chance to speak to John more about this as it was a busy few days, but hope to follow up with him soon on it.

    In the meantime the idea that DevOps starts with a beachhead or pocket of DevOps is one we have heard before. Carmen DeArdo of Nationwide has talked about how he has helped lead Nationwide’s DevOps transformation by  picking a few smaller but important projects that generated visibility for the rest of the organization to see that DevOps does indeed work.

    Of course Carmen is not alone in the concept of pockets of DevOps. We have heard similar from folks like Gary Gruver in his “Leading the Transformation” book, Damon Edwards and others espouse this approach. What is interesting to me though is the follow through we saw at DOES.

    I think we can all imagine that if DevOps works in a few projects, we would see it rolled out to more Dev and Ops teams.  What I think was really surprising was that it doesn’t stop there. The fundamentals and principles of DevOps are proving to be useful beyond the borders of developers and sys admins.

    One could say that it would be easy to see how adjacent players like QA and security admins would also see the benefits of DevOps. But as we saw at DOES London even HR and other business units are joining in the DevOps fun.

    This goes to something I have been saying for some time. While DevOps certainly originally referred to Dev and Ops, it seems to have outgrown the original intent. Maybe this is due to the fact that we never had a real definition or manifesto. In failing (not sure failing is the right word even) to do so, DevOps has been given a little more freedom to expand into areas that perhaps no one really thought it would. To me DevOps has become an umbrella term to refer to “the new way things get done”.

    Now granted this may not sit well with John Willis and some others. I respect that they have a more narrow view of what DevOps is and what it is supposed to be based upon their years in the trenches evangelizing and helping to drive DevOps adoption.  However, as I said I think it has grown beyond that and at least some of that is due to the hard work that people like John Willis, Patrick Dubois, Damon Edwards, Jez Humble and others have put in over the years.

    There were many sessions and speakers at DOES London on a wide range of topic as well. We did almost 40 video interviews that will be available on our YouTube channel, DevOpsTV. There will be a separate playlist for DOES London 2016. More videos will be added to that as soon as we receive the approvals from the participants.  In the meantime I wanted to show you one with my friend Helen Beal of Ranger 4 and Soren Pederson of Lego.

  • DevOps Chat: Christian Beedgen, CTO and co-founder of Sumo Logic

    DevOps Chat: Christian Beedgen, CTO and co-founder of Sumo Logic

    Christian Beedgen has years and years of experience in collecting large amounts of data and making it useful to Dev, Ops and security teams. I recently had a chance to sit down with Christian and talk about what is driving innovation in the data analysis market and how Sumo Logic is responding. While our conversation is short, Christian gives some great insights that I think you will find useful.

    Below is the streaming audio of our conversation and below that is the transcript so you can follow along.

    Enjoy!

    Alan Shimel:                Hi. This is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I’m very happy to be joined by Christian Beedgen, CTO and Co-Founder of Sumo Logic. Christian, I didn’t butcher your name too bad I hope.

    Christian Beedgen:     No, it’s quite fine.

    Alan Shimel:                Welcome. Christian, we had set this up some time ago that I wanted to interview you because there’s so much going on with Sumo Logic, but I realize maybe some of our listeners may not be familiar with the company yet though. So before we dive into some details, can you give us kind of a high level, a 50,000 foot overview of Sumo and what you guys are doing there?

    Christian Beedgen:     Absolutely. Sumo is a machine data analytics company. That’s a highfalutin way of saying that we’re doing log management. We have been around since 2010. The big differentiator that we brought to the market, among other things on a high level, is that we actually offer this as a service. So there’s nothing to install. It’s all focused on actually using the product to make sense out of your logs, out of your machine data for troubleshooting and analysis of application logs and everything up and down the stack basically.

    Alan Shimel:                Excellent. So logging as a service. And you’re right; the idea is a very 50,000 foot view of it. Christian, the dev-ops market of course is exploding and it’s a very hot area for tools vendor. Sumo Logic in particular, though, is always sort of at or near the top in terms of awareness among the dev-ops community. What do you attribute that to?

    Christian Beedgen:     Well, I think we are in a very fortunate position of having good product market fit basically. I come from this space of log management, as does my co-founder. We might not know much, but we certainly know a bit about how to build products that help people managing logs.

    Logs and anything that has to do with monitoring really are at the very center of any kind of operational activity. So it’s not a surprise to me that dev-ops folks are excited about what Sumo is doing, because it’s part and parcel of what they have to be able to do and I think we support it really well, and we end up in their toolbox more often than not.

    Alan Shimel:                Excellent. Christian, sort of the new messaging or new functionality that the Sumo folks seem to be really spreading right now is the idea of unifying logs with metrics. Can you give our audience an idea; what do you mean by that?

    Christian Beedgen:     I’m actually extremely happy to be able to talk about that because that has been cooking for a long time, and as of April we are now able to talk about it publicly. This goes back all the way in my mind to 2010. I’ve been wanting to do this for a very long time.

    From my own observation, of course at Sumo we’re running a pretty large scale distributed system, so we have a lot of insight into just from of our own sort of dog-fooding as to what we need in order to run a large scale system and in talking to customers and observing what they actually need in order to make their applications run better and troubleshoot them better and get them back in line better.

    Logs are certainly a very important part of that, but the other side of the coin when it comes to machine data are metrics. So what are metrics? Metrics are essentially time series data. It usually comes from the hosts. It starts with CPU, I/O metrics, network metrics, and then goes up the stack all the way into the applications, you know, how many logins per second, what’s your API response times, and those kinds of things.

    While those can be potentially captured in logs, logs are not necessarily the most efficient way of processing metrics. But metrics are extremely important and I think they kind of go together with logs in order to give you kind of a full overview as to what your systems are doing.

    We know about this need from our internal use, from our internal operations use cases, obviously, and we’ve heard it from customers as well that they don’t really like to do what we call sort of swivel chair analytics, where you have to like jump back and forth between different tools, one for metrics, one for logs, one for something else. We think we are in a good position to unify those things and this is why we are now basically bringing to market an additional metrics capability as part of Sumo Logic, and instead of building that as a second separate product, we decided that, hey, it’s really part of the same high level use case and sort of our unique proposition, value proposition there is, that we can do it in the same tool and we can kind of amalgamate the two different data sources and drive integrated use cases out of that, if that makes any sense.

    Alan Shimel:                Great. I just want to make clear to our audience. This is not officially released yet or it’s in a beta or early access form still or what is it?

    Christian Beedgen:     That’s correct. We have announced it. We announced it in April. We have obviously been working with design partners for a while. A number of our customers are actually using it as we speak, and we continue to get great feedback from them, and also, partially stuff that we now realize we probably still need to fix, you know, as usual when you’re deciding to roll out new functionality.

    We are currently planning to make this generally available by the end of July. So we’ll cross our fingers that we’ll hit that date. So it’s actually going to be in the market for everybody really, really soon. In the meantime, we allow folks to basically sign up to get onboard as early as possible and we’ve seen great interest in that as well.

    Alan Shimel:                Excellent. Now if any of our listeners who are not currently Sumo customers are interested in this, and I of course can see why they can, Christian, is there any place they can sign up for this or at least get more information, if not actually become sort of an early user or early access?

    Christian Beedgen:     Absolutely. Just to go SumoLogic.com and it’ll lead you there.

    Alan Shimel:                Great. Christian, if you don’t mind, we have a few minutes left and I want to sort of pivot a little bit. It’s basically my own thing. I actually just started writing – or finished writing a survey we finished up on containers and container technology. It certainly seems to be on the tip of everyone’s tongue. What are you doing? What’s your strategy around that? I want to ask a little bit about: does this pose a challenge for Sumo or a log is a log is a log?

    Christian Beedgen:     That’s actually a very good question. It actually turns out that we had to do a couple of things in order to stay ahead of the curve there, and that started in I think 2014. That’s kind of year that Docker broke, the way that I remember it. Then we started looking at what does this really mean, even for our own operations of course. But then there was a major voice coming from our customers, who of course jumped into this right away.

    It turns out that the way that you collect logs changes actually a little bit when you have the additional abstraction layer of a container. So we basically throughout 2015 wrapped our heads around that and figured out how to actually collect the logs from a containerized environment. There’s been a couple of iterations on that, of course obviously moving very fast, and they have also made some advances on how the logging works as far as Docker is concerned.

    But we now have first-party support for what I call sort of a comprehensive monitoring strategy for Docker. So that includes the logs as well as the metrics or what’s called stats in the Docker world, as well as these sort of Docker events and the additional metadata that can be queried out of Docker. So you know not just what the idea of your container is, but also what the images are that it’s running, et cetera. We can pull all of that into the Sumo and, on top of that, we have a really nice extension to Sumo that we call an app. That’s kind of our app for Docker that our customers are using.

    So it did change. The major change really came from the way that – technically speaking, the major change was that we had to do a couple of things in order to be able to collect they logs and the metrics, because that was basically the biggest change in terms of the low level stuff.

    At the higher level, the good news about the Docker stuff is I think that it provides a good amount of metadata, if you know how to get it, and mostly it’s with the Docker Inspect API that makes the analysis of the environment, which is now even more highly abstracted of course. You might not even know anymore which container runs on which source, et cetera. So there’s a lot of additional metadata that makes that actually really nifty. So I like that.

    Alan Shimel:                Very cool. Christian, we only have a few minutes left here, just another minute or two and I have two other things, two other questions on my list for you. Containers are certainly a very hot item. Dev-ops is very hyped. What do you think is next? What’s the next big thing?

    Christian Beedgen:     That’s one I think everybody is always thinking about that. There was a point when I realized what AWS Lambda actually was, and I was like, “Wow. That is really, really cool.” I don’t know yet exactly where it’s going to go, but I think it’s intuitive to me that in many ways Amazon has actually already invented the future after containers, and at the same time they were releasing the elastic containers. So I thought that was _____.

    Anyway, I think the term that has been emerging there is serverless, serverless computing. I think that is actually super-interesting, considering how complicated the stacks have become. It sort of adds yet another layer of abstraction, but basically one that destroys all the other underlying layers of the stack. I think that’s a really interesting thing that’s going on right now.

    Alan Shimel:                Sure, serverless computing for a no-ops age.

    Christian Beedgen:     There you go.

    Alan Shimel:                Let’s get rid of everything.

    Christian Beedgen:     Let’s make a t-shirt.

    Alan Shimel:                Yeah. Hey, once we get a t-shirt some VC will invest.

    Christian Beedgen:     There you go.

    Alan Shimel:                Anyway, Christian, last question because we are just about out of time. I often ask guests this. For people listening in, one book, if you can recommend one book to people that they should read that you find enlightening, helpful, must read, what would it be?

    Christian Beedgen:     The best thing that I’ve read recently is – oh, man, that’s a heavy-duty one. We are actually doing an internal book club on this and it’s been blowing people’s minds. There’s like matter all over the place. It’s called The Principles of Product Development Flow by a guy called Reinertsen. It’s kind of a second generation Lean applied to product development. The guy’s an academic. I love that book. I think it’s kind of mind expanding, so The Principles of Product Development Flow. That’s an awesome book.

    Alan Shimel:                If it’s on Amazon, I’ll try to include it in the show notes, so people can go look at it. Great. That’s a great suggestion and thank you. Christian, we’re over-time actually, but it’s okay, not too bad. I wanted to thank you for joining us on this edition of DevOps Chats. Continued success with Sumo Logic and we hope to check back in on you soon.

    Christian Beedgen:     Sounds good. Thanks for having me, Alan.

    Alan Shimel:                Okay. Christian Beedgen – and I know I always mispronounce his last name – but CTO/Co-Founder of Sumo Logic, thanks for being this week’s guest on DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. Until next time, have a great day.

  • Austin & Chef Give ChefConf 2016 That Warm, Fuzzy Feeling

    Austin & Chef Give ChefConf 2016 That Warm, Fuzzy Feeling

    I have written before about the DevOps community in Austin. It is one of the most welcoming and warm groups of people I have ever interacted with. Combine that with the HugOps operation of the friendly folks of Chef and you wind up with a great experience. That pretty much sums up ChefConf 2016 for me. Beyond the warm and fuzzy though, there was also a lot on display on what the future of business is all about. To paraphrase a line from the movie, The Graduate, I have one word for you: AUTOMATION.

    Automation was on full display at ChefConf 2016. And not just your grandpa or dad’s automation either. For those who think Chef is still all about configuration management and automating servers, think again. I am talking about automation extending into every nook and cranny of the business. You only had to see Alaska Airlines CIO, Veresh Sita’s presentation to understand what automation really means. But truthfully that was just one of many talks and sessions that demonstrated the power of automation and how Chef is pushing automation up and down the business.

    There was also the announcements regarding Chef Automate and Habitat. While we have covered Habitat already, a quick word on Automate. Automate which is years in the making, is actually the combination of Habitat, Chef Delivery which was released last year and defines the DevOps workflow, Chef itself and Chef InSpec, the compliance and security project based on the technology from the acquisition Chef made last year of VulcanoSec. All of these are combined in one enterprise class package that Chef CEO Barry Crist called “our flagship product”.

    Beyond that though to really give you a feel if you couldn’t make it to ChefConf this year, there was a palpable buzz around the place. I think the feeling is that so many good things are starting to come together. While many label many of these under the DevOps umbrella, it is automation, DevOps, Agile and more combining to enable businesses to do more, faster and better than they ever have before. In addition, as these trends continue to evolve and accelerate the pace of innovation also continues to accelerate.

    I had a chance to speak briefly with Dr.Nicole Forsgren, who works at Chef but is also one of the key people behind the State of DevOps survey. Forsgren said that is why we are seeing the gap between high performing IT led companies and those who are not continuing to widen. The gulf will continue to grow as companies adopting these practices pull away from those who do not.

    From my point of view it is amazing to see that since I first became involved in IT we have seen IT move from a cost center as viewed by many an executive to the engine that drives the business.  As I remarked to several people at ChefConf, we certainly live in interesting times!

    I was also able to use the Chef Newsroom to do a few interviews there. We have put them up in our DevOpsTV Youtube channel under ChefConf 2016 playlist. There are about 8 or so total but I am embedding two to give you a taste. You should check out the rest if you have a chance, as they are pretty good.

    The first is with George Miranda of Chef and we talk about Habitat and a little about Automate.

    This second interview is with well known DevOps journalist, writer and community member, Ben Kepes, enjoy!

  • DevOps Chat: Sanjeev Sharma, DevOps Enterprise Summit London 2016

    DevOps Chat: Sanjeev Sharma, DevOps Enterprise Summit London 2016

    I had a chance to speak with CTO of technical sales of DevOps for IBM right before the recent DevOps Enterprise Summit in London. I also interviewed Sanjeev at the DOES London event and that video will be available shortly, but I wanted to give you a preview of what he was speaking about in case you didn’t get a chance to attend DOES London 2016.

    Below is the audio file of our chat and below that is a transcript of our conversation.

    Of course Sanjeev is a frequent contributor  to devopsy.kinsta.cloud and you can read more of his articles here.

    Alan Shimel:                Hi, everyone, Alan Shimel, Editor in Chief of devopsy.kinsta.cloud and we’re here with another DevOps Chat. Today’s guest is Sanjeev Sharma, CTO of Technical Sales of DevOps IBM. Sanjeev, I mangled that probably. Why don’t you correct me?

    Sanjeev Sharma:         Sure. No, Alan, you got it right. My title is CTO for DevOps Technical Sales. I’m a Distinguished Engineer here at IBM and happy to chat with you, my favorite topic, DevOps.

    Alan Shimel:                Yeah and always happy to have you on, Sanjeev. Sanjeev, today, specifically, I wanted to talk a little bit about the upcoming Gene Kim’s DevOps Enterprise Summit event taking this Thursday and Friday, June 30 and July 1, over at the Hilton Metropole in London, England. You, of course, I think are handling or moderating a panel at the event. Correct?

    Sanjeev Sharma:         Yes, sir. Yes, Alan. I’m really excited about it, and as you know, Gene has been hosting these events. This is his third year, if I remember correctly, but this is the first time he’s having it in Europe, so very excited about it. IBM, of course, is a sponsor for the event, but I also have the privilege of hosting a panel.

    On the panel, we’ll be focusing on how to assess a large enterprise’s readiness to adopt DevOps. People ask about – ask the question, “How long does it take to get from here to London? I live in Washington, D.C.” Well, I have to ask them the question, right? First of all, where in London do you want to go? Secondly, where in Washington, D.C. do you live? It can take you about an hour just to get to the airport. Knowing your Point B, where you want to go, and knowing where you are, your current state, your Point A, is very important. We will be focused on that.

    I’m pleased to have a very exciting panel. I have the leader of DevOps adoption at Lloyds Bank with me on the panel, Mark Howell. I have a VP of Application Development from Monetize on the panel with me, and then I have my peer, Rosalind Radcliffe, who is the CTO for DevOps Architecture for our Enterprise Organization aligned here at IBM. She comes from the mainframe side of the world, also as a third panelist, talking about this topic.

    Alan Shimel:                Got it. Sanjeev, before we jump exactly or primarily into the panel, as you said, this is the third year for Gene’s DevOps Enterprise Summit, first year in London. It’s happening at an auspicious time after all of this Brexit, right on the heels of it. For those who may not be familiar though, they’ve never had the chance to attend a summit, you have, obviously. Can you give our audience an idea of what the summit or what these DevOps Enterprise Summits are about? What are they trying to do? Then, we’ll dive into it specifically.

    Sanjeev Sharma:         Sure, Alan, sure, sure. I think DevOps, as folks listening to this and people who follow your phenomenal devopsy.kinsta.cloud probably realize, it came from – had its origin primarily in what we like to call the “unicorns” of the world, the cutting-edge companies, the startup companies, who are normally leaps and bounds ahead of your traditional enterprise.

    Gene Kim started this event. I think he had this as the tagline for his first one, I don’t know if he still uses it, saying, “DevOps is also for the horses, not just for the unicorns.” Right? The focus of this event is how are large enterprises, with all the complexities, the legacy, the sheer inertia of it, which comes from the size of them, how are they adopting DevOps?

    We, obviously, at IBM found that very exciting because that’s our sweet spot. Every DevOps Summit I’ve attended, the speakers Gene has been able to go find, and of course, being from IBM, I have to look at everything a little bit through my own lens, but this is not a vendor-specific event. It is totally agnostic. It is people sharing their real-life’s journeys of adopting DevOps, what stumbling blocks they encountered, what challenges they had to overcome, and these challenges, while they vary from company to company, the ones, if you’re a large enterprise with a large legacy install base, with a large distributed set of practitioners, vendors, and business partners, outsourcers, geographic time issues, these are common problems.

    You hear a lot at this summit about how large organizations are addressing these challenges, which companies face. For anybody who does not work in the proverbial startup with the proverbial “two-pizza” team, but works in such an organization, I think this is a must-attend event. This will be actually my first time speaking. I’ve attended the previous events, but I’ve not had an option to present or speak, so I’m really looking forward to it, to be a part of the action.

    Alan Shimel:                Got it. Sanjeev, thank you. That was actually dead on, and I hope that gives people a good sense of what the DOES shows are about and why they may want to attend. Let’s now jump in though. As you mentioned, you’ve got a great cast. I’ve met the gentleman from Lloyds Bank, and for those maybe on this side of the pond who aren’t familiar with Lloyds Bank, would you call them a mid-size or a large bank, as banks go, Sanjeev?

    Sanjeev Sharma:         I would qualify them as a large bank.

    Alan Shimel:                Yup. What’s interesting, and I always find this interesting when you talk to DevOps people, Sanjeev, is we think of financial and the whole financial industry as being rather conservative. But yet, when it comes to new technology, such as DevOps, or I don’t want to say new, but a little more out there technologies and things such as DevOps, we see large banks and financial institutions, whether they be insurance, banks, but finance, really kind of leading the way here. Lloyds Bank is, I think, a great example of that.

    Sanjeev Sharma:         Yes and I think, in fact, both the companies I have on, Monetize is the second panelist. In fact, Garret Evans, who was a VP of AppDev at Monetize, is the other panelist other than Mark Howell from Lloyds. They’re both in the financial services industry, and they both come at it from kind of a different angle in the sense that Monetize is a service provider, and you would call them as a company. They’re not a bank themselves. They provide services to financial organizations, and they’re on the cutting-edge of technology. They’re way ahead of their – on the innovation forefront, and Lloyds too. But Lloyds still has that whole legacy, like more large banks, still has the legacy, “keep the lights on” applications that they to run.

    But it is interesting what you mentioned about how financial services, which we, until a few years ago, one would think of them as the slow plodding conservative people in their suits and ties and risk-averse, being at the forefront of DevOps adoption, and that is very true. They are a prime example of how adopting things like Agile and DevOps actually reduced your risk, actually makes you agile in a disciplined and organized manner, as an organization, rather than some people’s view of it being the Wild West.

    I think they’re a prime example. Why are they doing this? They’re doing it because of all the industries out there, they are one who are going through probably the most transformative change in their existence they’ve ever had. Financial services, banking, peer-to-peer lending, peer-to-peer money transfer, these are all undergoing a massive transformational change. They’re getting challenged by these FinTechs, or financial startups.

    I think this has become a very interesting place for them, and I worked with financial services, it’s kind of my core industry, all over the world. Right? When you go to the developing nations, you see these financial services companies facing the challenge of, “How do I go and reach the un-banked populations who need banking services without – but cannot access a traditional bank?”

    Then, in the developed world, you have this challenge of, “HOw do I go access the Millennials, who, again, do not want to go into a traditional bank, but need banking services, but do not consume and access those banking services the way you and I, and the folks with much more grey hair than them, are used to doing so?”

    It is ripe for transformation, ripe for disruption, and DevOps provides that enablement for the IT organizations in these financial institutions to be ready for the disruption and enable it, and not be the inhibiter, but be the enabler.

    Alan Shimel:                Excellent, absolutely. Sanjeev, we’ve left an important person out of your panel though. Haven’t we? Besides yourself and the two financial institutions, we also have Rosalind Radcliffe on here.

    Sanjeev Sharma:         Absolutely. I didn’t want to – I’m not intending to ignore her [chuckles].

    Alan Shimel:                Why don’t you give our listeners a little background? Rosalind has been a frequent guest on our podcast, but for those who may not be aware, why don’t you give them a little background?

    Sanjeev Sharma:         Absolutely. Rosalind is my peer. She’s also a Distinguished Engineer here at IBM. She’s in the Development Labs in our Enterprise Modernization side of IBM. She focuses on the very – to simplify it and make it very generic – on the mainframe end of the world, although, her influence extends across to all aspects of DevOps, and she’s been a great person we’ve worked with, a great partner, in expanding IBM’s DevOps capabilities.

    She actually has her own session also, I think, a couple of sessions before my panel, where she’ll be talking about DevOps and how it’s adopted in the mainframe world, especially talking about testing, which is a major area where we’ve seen a lot of traction when it comes to DevOps adoption on the mainframe.

    She is going to be bringing to our panel the mainframe point of view, and I’m generalizing here when I say “mainframe.” Right? It could be Systems Z, or Series I, or large traditional legacy systems, but bringing that because if you look at large organizations, especially large organizations who have been around for a while, be it they’re banks, or retail, or government institutions, and those which are transaction heavy, they still rely on the mainframe to run their core businesses.

    How they are adopting DevOps has been a surprise, a refreshing surprise, so to speak, in the sense that a lot of these large organizations have come forward and their mainframe teams have the lead of saying, “We want to adopt DevOps first.” It is unique, and when we tell people that, they’re usually surprised going, “Mainframe?” One usually thinks of them as being at the laggard end of adopting new technologies and new processes.

    But we have found that to be exactly the opposite. I’m sure there are organizations out there where their mainframe teams are going, “Hey, it’s not broken. Why should I try to fix it?” but most mainframe organization’s mainframe teams are in the process of modernizing their application-delivery capabilities. I think DevOps has given them the opportunity, the platform, and the capability to move into the modern world. There’s a significant C-change going on in how customers are consuming the mainframe.

    Linux’s own mainframe is a great example. OpenStack’s own mainframe is great example. And, of course, the z/OS, which IBM’s operating system for the mainframe has also evolved and become extremely modern. She has a very – is going to be able to bring a very unique perspective, which I think will apply to a lot of the attendees, so I’m very fortunate to have her on the panel.

    Alan Shimel:                Absolutely. Sanjeev, believe it or not, we’re almost out of time already, but real quickly, specifically now to your panel, give me, if you can, three reasons why it’s a must-attend panel for those who may be in attendance in London.

    Sanjeev Sharma:         Sure. Number one, people don’t want to hear theory, and I’m sure all our attendees, or our listeners who have the opportunity to attend, don’t want to come and listen to theory. I mean you can Google DevOps, you to YouTube, watch 100 videos on the theory of DevOps, read some books. People want to hear how a company actually undertook that journey and succeeded with it. Right?

    That’s what we have on this panel. We have three examples of people, and I’m not even counting my own experiences working with the dozens of companies I’ve worked with in my role. My goal is not to talk there, but be the facilitator, but the three people we have on the panel are bringing tons of experience, real-world experience, and they will be, hopefully, sharing very openly. I know these folks. I know they’ll be sharing very openly and are willing to talk about all the pitfalls and the speed bumps they hit along the way, so real-world experience.

    Number two, it’s an interactive panel. We are going to have no slides, maybe one slide in the beginning just so people know who we are. The idea is – in fact, we are going to do it very uniquely. I’m going to have my iPad up there with me, with these organizations, both Monetize, Lloyds Bank, and Rosalind. They’re going to give me some drawings before and which I’m going to draw out during the panel, so people can, in real life, see real-life versions of what their application delivery pipelines and their architectures look like, and what changes they needed to make.

    Thirdly, we are going to focus or talk a lot about culture because the biggest bottleneck, the biggest inhibitor to adopting DevOps, is cultural inertia, especially in a large organization. Right? Things have been going on for a while. This is how we always do things, always start things. The responsibility is not mine. It’s not broken. Why should I try to fix it? These are all the specific examples of cultural inertia. We intend to spend a lot of time talking about how, in a large organization, which has set ways of doing things, which have highly distributed teams, how does one overcome that cultural inertia?

    I would say those are three very good reasons to come to our panel. We are on Thursday, I believe, at 2:45 PM, but please check the agenda, they’ve been moving things around on the agenda, for the final time and location, but come there. Our plan is to open it up for questions from the audience, so you’ll be able to ask your own questions, and, of course, all of us panelists will be around for the entire event to meet with you and answer any questions one-on-one also. I hope to see you all there.

    Alan Shimel:                Absolutely. Sanjeev, thanks for giving a quick preview of both DevOps Enterprise Summit and the great all-star panel you’re hosting there. I will be there. We’ll be filming. I think we’re actually going to video interview, so we’ll follow-up then. But for anyone who is attending DevOps Enterprise Summit in London, please be sure to take in Sanjeev’s panel. As most things Sanjeev does, I’m sure it will be a great event.

    For those who are considering going to DevOps Enterprise Summit in London, I highly encourage you to do it. If you can’t make London though, the San Francisco version of the event will be in the fall, and I encourage you to go there. Sanjeev Sharma, IBM, thanks for being today’s guest on DevOps Chats.

    Sanjeev Sharma:         Thanks, Alan. Thanks for the opportunity and I look forward to working more with you.

  • DevOps Chat: Habitat by Chef with Julian Dunn

    DevOps Chat: Habitat by Chef with Julian Dunn

    julianI had a chance to speak with Julian Dunn, product manager for Chef ahead of the upcoming ChefConf conference in Austin Texas next week. Julian and I spoke about Habitat, Chef’s new open source application automation project.

    Many in the industry are hailing Habitat as something really special. Our own Tony Bradley says it could be a game changer.  Julian gives us some of the background and reasons why Habitat is important for you. He also gives us an advance look at the three Habitat related sessions scheduled for next week at ChefConf.

    If you are already going to ChefConf, be sure to hit all three of these if you can. If you are in the Austin area next week, try to make the show. We will be there covering it live.  Also the opening keynotes for Tuesday and Wednesday are being live streamed over the web.

    In the meantime here is my conversation with Julian with the printed transcript below, enjoy!

    Alan Shimel:                Hi, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat, and I’m happy to have Julian Dunn, Product Manager of Chef joining us today. Good morning, Julian, how are you?

    Julian Dunn:               Good morning, Alan, I’m doing very well. I’m melting a little bit because it’s very hot in New York, but you know, other than that—perfect summer day.

    Alan Shimel:                Yeah, it’s July in New York, it happens. Julian, we could talk about weather, I’ve certainly been traveling enough to see different ones, but let’s focus in a bit on what I wanted to really talk to you about today, and that is Chef’s new Habitat offering. Let’s assume a listener doesn’t know what Habitat is at this point. Give them a quick kind of elevator pitch on it.

    Julian Dunn:               Yeah, absolutely. Now, if you’ve read any of the materials and things like that, we’re using this tagline called Application Automation. And, you know, what on Earth does that actually mean? Well, what is the problem that Habitat solves for people?

    So, you’re an application developer today, and what you end up doing as an application developer is—well, what you want to do is, you want to spend a lot of your time doing the business logic and writing the business code that is actually gonna differentiate you from your competitors, right? So if you’re working at JCPenney, let’s say, you’re trying to write features for JCPenney’s website or mobile application or whatever to differentiate you from Macy’s and Target and Nieman Marcus or whoever your competitors are, right?

    Well, the experience of being a developer today actually ends up being that, before you write any of that program code, you have to spend a lot of time in the weeds and dealing with what I call sort of the plumbing oriented aspects of doing the programming, right?

    So just imagine if you were an interior decorator and you want to simply decorate your bedroom to whatever you wanted in there—you know, damask curtains and what have you—but you’ve spent most of your time dealing with the electrical and the plumbing. Not a particularly nice experience.

    Alan Shimel:                Mm-hmm.

    Julian Dunn:               The other thing is that, when you make those choices about what plumbing and what electrical systems you’re gonna use, that actually changes how your room is decorated. I mean, how absurd would that be, right?

    Alan Shimel:                Mm-hmm.

    Julian Dunn:               And so the notion of trying to let the application develop or be able to concentrate mostly on developing their program code and make a lot of those infrastructural choices later led us to develop Habitat, which is something that takes a little bit of a different approach than how we’ve built IT systems in the past, right?

    It’s kind of back to my analogy of the plumbing. In the past, we’ve built sort of up from the bottom towards the application, right? So we choose an operating system, we choose a bunch of stuff that sits on top of the operating system. You eventually at some point, we reach the application, right?

    And that’s an incredible waste of time for the application developer, who actually wants to start up here and define what their program logic is, right, and how that application should behave in a lot of different scenarios. And if you sort of start at the top and move towards the infrastructure, that’s the surface area that you actually end up owning as the application developer—we believe that that is Habitat.

    Alan Shimel:                Very cool. And hence the name, then, right? When you explain it that way, the name Habitat actually makes a heck of a lot of sense.

    Julian Dunn:               That’s right.

    Alan Shimel:                Yep. So, Julian, this is, some would say, you can see where Habitat is analogous—not analogous, adjacent to kind of the space that Chef plays in already. It’s a much bigger mission, if you will, than just what Chef has done to date. Is that a fair statement, you think?

    Julian Dunn:               It sure it, it sure is. You know, Chef, I think, initially started out, obviously, right, with a configuration management product that was very infrastructure oriented. And, over time, you’ve seen that our product portfolio and what we’re trying to do is a lot larger than just infrastructure configuration management, right?

    We kind of describe ourselves today as an automation company. We solve a bunch of automation problems, wherever automation is needed to help reduce people’s time to market or burdensome activities that they need to do in a regular ________, right? To really free people up, no matter what their problem domain is to being able to do the really intelligent parts of their job—the thinking parts of their job, right? And you’ll see that as we released Chef Delivery, which is a workflow system that allows people to basically implement, if you will, the principles that are in a lot of the books out there like Jez Humble’s Lean Enterprise that tell you, “This is the shape of how you should be delivering the software out to production.” Basically something like Chef Delivery is an automation arrayification or that technology—or those ideas, right?

    And then when we made the acquisition of VulcanoSec, which is the German security company, that gave us in-spec and Chef compliance that’s automating the work of compliance officers, security officers—right, folks that spend a lot of time, their job today and their pay and their experience is they spend a lot of time manually poking around systems and putting up fires manually because they don’t have a good framework and a system for describing the correctness of a particular system, right?

    And so now, as we move into—right, we’re, as a product organization, you want to be one that’s trying to address people’s pain points, right? When we started looking at what the pain was for an application developer, and they spend so much time dealing with the nuts and bolts of actually writing the code, we’re like, “How—why are systems built in this way?” We really went down a path of inquiry and we came up with Habitat as a way more application developer-centric than the perhaps infrastructure-centric things that we’ve built in the past.

    Alan Shimel:                Sure. Just two thoughts on that, Julian, I’d like to explore with you. One is—look, I’m not, I don’t hold myself out to be a Product Manager at Chef or anywhere near that integrated into it. But it feels to me, anyway, that the Chef compliance and the Chef delivery are very tactical pieces that embrace and extend Chef’s core configuration management capabilities, right?

    Where Habitat to me is more of a strategic rather than tactical type of play here, where you’re looking to set the game—the grounds, right? The stadium that we play in, whatever you wanna call it, the field, right? And so it’s a different—and again, I might be wrong, I’ll defer to you—but it feels different to me.

    Julian Dunn:               It is different in the sense that it’s a little bit iconoclastic, you’re right, in that it challenges some of the approaches that folks have been doing to try and deploy applications and get the sort of modern application characteristics that they want out there. And those characteristics are really great. I mean, one thing that’s really—as we developed this product, what really caught for us was to focus in on, “What does a modern application look like? What characteristics does it have?” And those characteristics are things like, it should be deployed immutably. It should be deployed atomically in that it’s either installed or it’s not, right? It should have certain characteristics built in. It should be aware of—it should know how to behave when it’s deployed in different scenarios, right, in different, what we call topologies.

    Alan Shimel:                Mm-hmm.

    Julian Dunn:               So you can think of, on a develop laptop, you might just have one instance. In a production environment, you probably have a number of instances, and they would have some relationship with one another, right? They might have one where you send all the rights two and the other ones are the reads, right? There might be some that are—like, think of a caching system, right? They right be hierarchical where there’s sort of a first, second, and third layer cache, like Squid or something like that, right?

    So it’s relationships between these entities, these application components, and one thing that we realized as we’re developing Habitat is, you know, as folks develop more complex applications and those applications are actually distributed systems, folks haven’t really spent a lot of time figuring out how to describe those relationships in a way that it imbues the applications themselves with the understanding about how they’re related to other components, right? The ways in which people have tried to solve the relationship problem between these components is to create sort of a central system, an orchestrator, if you will, that defines those relationships.

    And the trouble with an orchestrator is that it becomes a single point of failure, and as we know, that’s not really compatible with the cloud, right? Where in the cloud, they tell you, “You really shouldn’t have single points of failure, because you’re on an unreliable fabric,” right? So you really should have a system that knows how to recover and continue to function in the face of failure one or additional components, right?

    And so that’s where we started to come about with the architecture and the design of Habitat and how aware—how self-aware these individual components should be.

    Alan Shimel:                Absolutely. Just one other kind of comment or observation, and that is, you’re right—configuration management and compliance seem to be operational, or at least lead with operational, where Habitat clearly is a pay in the developer specter. But it’s all supposed to be one under DevOps, right? I mean, we don’t want to—I’m not into creating divisions between developers and operators, and I’m sure you guys aren’t, either, Julian.

    Julian Dunn:               Right, but I’ll tell you

    Alan Shimel:                But clearly they’re different focus—go ahead.

    Julian Dunn:               I was about to say, Alan, you know, the dirty of secret of DevOps, my observation, you know, I’ve been doing this for a number of years, and I’d love to hear your thoughts on this. But my feeling about the dirty secret of DevOps, and I go to DevOps Days and these conferences, and you survey the audience and you look at who the folks in the room are, right? And it’s something like, if you’re lucky, it’s still 80 percent Ops and 20 percent Dev, right?

    Alan Shimel:                It is, it’s OpsDev.

    Julian Dunn:               Yeah, right. So DevOps has been very much about Ops taking a lot of the good practices from Dev and learning a little bit of coding and learning that there’s a proper workflow and that you should have tests for stuff, but even if you’re not doing automated tests like Chef does, at least you should have some system for testing stuff before you just go log into a box and make changes in production and whatever.

    It’s almost like there’s this information flow that’s gone one way, but the information flow hasn’t really gone in the other way, even though we’ve had a number of iterations and generations of this technology. And so when we started asking the question, why—why have we kinda gotten from the brick wall to sort of more an English hedgerow, if you will, between Dev and Ops? How can we further develop capabilities to break down even the English hedgerow, if you will?

    Alan Shimel:                Makes a lot of sense. So, Julian, unfortunately, we’ve only got 12 or 14 minutes here and we’re running out of time. There’s a couple other things I wanted to hit. We’re recording this just the week before ChefCon, which is next week down in Austin, Texas—July 12th and 13th, or 11th, 12th, and 13th, technically. And, of course, I’m sure you’ll be there. Will there be a lot of Habitat kind of information and presentation?

    Julian Dunn:               There will. There’s gonna be three major talks, and we’re sort of billing them as the Habitat 101, 201, 301 kinda talks, right? We’re gonna have an intro and then sort of how Habitat fits into the ecosystem is sort of the 201 level talk, and then there’s a deep dive into why we made the technological choices that we did, the system design, and things like that, and that’s the 301 level talk.

    At ChefCon, we’re also gonna have something called the Habitat Zone, and we’ll program that with a few talks as well. The speakers from the 101, 201, 301, they’re gonna answer the Q&A in the Habitat zone, and that’s gonna be near the registration area. We’ll also have sort of community building—that’s one thing I didn’t mention, I don’t know, Al, if you mentioned it, but Habitat is a fully open source project.

    Alan Shimel:                Yeah, under an Apache 2.0 license.

    Julian Dunn:               Under the Apache 2.0 license, and we believed that that, we needed to make it open source to really engender a great community, similar to how created a huge community around Chef and, you know, just ways in which folks can contribute to that Habitat community is by writing plans that can build packages that live within the Habitat ecosystem.

    There’s, you know—just think of how many packages are out there within a typical kinda Linux distribution, right? There’s a lot of surface area that we would want to cover with people creating Habitat plans. That’s a great way for folks to get started. We’ll have some programming in the Habitat Lounge to talk about that with folks.

    Alan Shimel:                Yep. Julian, I’m gonna do my best to at least get the audio of this up before, in the next day or so if I can’t get it today.

    Julian Dunn:               Great.

    Alan Shimel:                And anyone hearing this, if you are in Austin or near Austin and you’re not already going to ChefCon, you really should look into it. You can get information, I guess, at getchef.io. I’m sure it’ll be listed there, just Google ChefCon.

    Julian, unfortunately, we’re just about out of time, but you know what, maybe we’ll pick this up down in Austin and we’ll do a part two or something.

    Julian Dunn:               Great.

    Alan Shimel:                Absolutely. I want to thank you for joining us today on DevOps Chat, and great—you know, I’d love to see Habitat really take off, here, and continued success to Chef and all the gang there.

    Julian Dunn:               Absolutely. Thanks very much, Alan.

    Alan Shimel:                Okay. Julian Dunn, Product Manager of Chef, thanks for appearing on this episode of DevOps Chat. We’ll see everyone next time. This is Alan Shimel for devopsy.kinsta.cloud.

  • DevOps Chat: Nathen Harvey, Chef

    DevOps Chat: Nathen Harvey, Chef

    I recently had the pleasure of catching up with Nathen Harvey of Chef. And I do mean catch up. As VP of community development, Nathen keeps up an amazing pace of visiting Chef communities around the world. In this role who better to understand what DevOps practitioners are seeing? Nathen and I spoke about several things including Chef’s security and compliance capabilities.  Below is the streaming audio of our conversation and below that is a transcript of our discussion to follow along.

    Enjoy!

    Alan Shimel:                Hi. This is Alan Shimel for another DevOps Chat here on devopsy.kinsta.cloud. Today’s guest is Nathen Harvey, VP of Community Development at Chef. Hi, Nathen. How are you?

    Nathen Harvey:           Great, Alan. How are you doing today?

    Alan Shimel:                Good. Nathen, I’m going to bet that most of our audience already knows who Nathen Harvey is and what your role is at Chef, but maybe for the few who are unfamiliar, why don’t you give our audience a little bit about what it is you do as a VP of Community Development at Chef?

    Nathen Harvey:           Yeah. I get asked that question a lot, Alan, and I’ll tell you that the real definition is this. There are two parts to it. The first being VP of Community Development means that none of my code runs in production and that makes the world a much safer place, if we’re being honest.

    Alan Shimel:                Okay.

    Nathen Harvey:           The second thing is before I joined Chef I did actually have code that ran in production. I actually managed a bunch of production infrastructure. So when I moved from an operations role into a community management role, the thing I like to say about that is I put down the pager and I picked up the bar tab. Oddly though, I’m up at 3:00 AM either way.

    Alan Shimel:                Yeah. Well, I think that’s just part of today’s work environment, where everyone is up it seems at 3:00 AM, depending where you are in the world.

    Nathen Harvey:           But joking aside, it’s really about going out and meeting with our community and helping fuel the love of Chef, helping folks in companies large and small get better at automation, get better at dev-ops, get better at great software development and infrastructure practices.

    Alan Shimel:                Yeah. And, Nathen, you’re not kidding about seeing people the world over, too, as part of your role, because I follow you on Twitter, I follow where Nathen is speaking, and whether it be a local meet-up group or a Chef users’ group or a conference or customers, you literally are traveling the world constantly.

    Nathen Harvey:           Yes indeed.

    Alan Shimel:                Yes, preaching the Chef message. Nathen, I wanted to focus our talk a little bit today around one of my favorite subjects, security, infosec, whatever you want to call it. Chef has become one of the leaders and has been for some time – one of the leaders in security within the dev-ops movement, if you will.

    I had the pleasure of becoming friends with Justin Arbuckle a year, year and a half ago. Justin was out preaching – what was it – compliance at Velocity or something? I may be mistaken.

    Nathen Harvey:           That’s right, compliance at Velocity. You bet.

    Alan Shimel:                You know, for a long time and it resonated with me. Then of course I think Chef made an acquisition, a European company who sort of had a compliance vulnerability scanning for code.

    Nathen Harvey:           Yes.

    Alan Shimel:                And now you guys have really kind of laid down the gauntlet on this and really put the pedal to the metal in talking about why it’s important to do this and why it’s important to do it earlier. I don’t want to steal your thunder. Can you give our audience a little bit of your opinion on why it’s important and what should be done?

    Nathen Harvey:           Yeah, sure. Look, Alan, in a traditional way of developing our software we all fall under some sort of regulatory burdens. We all have auditors or other security controls that we need to make sure are implemented within our production systems, and the traditional way of doing that, at one point in your development workflow you might introduce a security scan into the development workflow itself before you go to production, but usually that ends up just being a blocker for moving flow, moving change across your organization.

    So you’ll oftentimes pull that security scan out and then just start scanning your production systems. But for me, scanning the production system is kind of like the oil light on your dashboard. When it comes on, it’s too late. You have to have solved that before you get into the production environment.

    So at Chef, really we look at our roots with automation and our ability to fully customize and fully automate the buildup and the maintenance, configuration management of your infrastructure over time, your infrastructure and your applications. We say that we need to make sure that we’re always in compliance, but it’s also very important for us that we start to adopt more of the development workflow, more of the software engineering principles.

    One of those principles of course is that we should do test-driven development. Well, why not take those controls and those audit controls that you have to enforce and move those directly into the development workflow? You certainly see many cases where you’re doing, say, static code analysis during your continuous delivery pipeline or during your continuous integration. But what about moving that even further back and doing not only static analysis of your code, but also actually testing what does the running application actually look like? Is it exposing ports that it shouldn’t? Is your infrastructure configured properly? And can you do that on the developers’ workstations, move that -? We like to say you’re moving compliance to the left. If you think about your change flows from left to right, from your developer’s workstation all the way out to production, how do we get and start thinking not about how to scan the production environment better, but instead how to start making those controls into your developer’s workflow?

    Alan Shimel:                Yep. Nathen, as a security person that’s almost radical to me. I will tell you, having spoken to many security people about this, we actually put on a DevSecOps day, a Rugged DevOps day at the RSA conference last year in San Francisco and Justin spoke there. A lot of security people, this makes them very nervous, believe it or not, Nathen, because it’s not them doing the scan. We’re going to ask developers to scan their code on their workstation, while I’m not there to see it, right, or not there to make sure that the code is right?

    Nathen Harvey:           Right, right.

    Alan Shimel:                Go ahead. I’m sorry.

    Nathen Harvey:           Let’s look at that. In the past, and I understand where these security folks are coming from, but if we look at today’s enterprise and the way that software is built today, security folks want to be the ones that are doing all of the scans, that want to be the ones that are making all of those assessments. On the one hand that’s fine. They should absolutely be involved in those assessments. But, frankly, if it’s the security team only that’s responsible for that, it’s simply not going to get done. The security teams aren’t big enough; don’t have enough capacity to keep up with the rate of change. They’re going to become a blocker in the enterprise and that’s going to become a real problem.

    So it’s really that security professional’s goal or the way that they need to look at this is, first, automation makes their job much, much easier. Not only can we remediate things that are found much, much faster, but we also gain consistency and things like that.

    But if we can then partner with the development team, with the engineers that are building out those systems and get them to think of security as a first level concern and compliance as a first level concern and start being partners with us, like we’re partnering with them, we’re not abdicating our responsibility to them. Frankly, some of the scans that the security team is going to run in the production environment, they’re still going to run those, but what we’re going to find by giving developers better tools to run those scans sooner, to ensure compliance earlier in the process, that those scans are going to find fewer and fewer vulnerabilities, and those vulnerabilities that are found we’re going to be able to address and remediate much, much faster.

    Alan Shimel:                And I might add, Nathen, not only much, much faster, but much, much cheaper. I mean I’ve seen studies where it’s something like 10x to 100x cheaper to take care of a vulnerability or a compliance issue at that shifted left stage, where it’s still on the developer’s workstation rather than on some cloud instance. Right?

    Nathen Harvey:           Absolutely. That may feel radical, but it’s really just we’re going back to our roots. I mean we’ve known for decades that fixing a bug in the development process is much less expensive than fixing it after that bug has been released into your production environment. The same is true for a security control or a compliance control.

    Alan Shimel:                I agree. I agree with you. Nathen, I have another issue I wanted to touch on with you, and that is some people get hung up on the compliance, the C word, so compliance versus security. They’re not synonymous, right?

    Nathen Harvey:           They are not. They are not at all synonymous, no. I think that compliance – Alan, let’s think about this. You have a CEO at a company who has to sign off and agree to – have auditors come in and assess whether or not they are compliant. Frankly, when an auditor walks in the building, there are many, many organizations who say, “Our number one objective when the compliance person walks in, when the auditor walks in is to get them to sign off on our audit and leave as quickly as possible. I don’t want them meddling in my business. I want to get them out of here.”

    Alan Shimel:                Yep.

    Nathen Harvey:           So with that approach, what we really do is try to make sure that we can run compliant systems, and compliance is there so that we can assess whether or not we are secure, but security really needs to – it’s a different mindset than compliance. Compliance sometimes is the easier place to start. I want to make sure that my audits are passing. When I have audits that are passing, I can sleep at night knowing that my audits are going to pass. Then I can start to look broader at the system in terms of: am I actually building a secure system? But, frankly, security is the foundation and compliance is what sits on top of that.

    Alan Shimel:                Yes, absolutely. Nathen, the other thing I think that really has enabled – and maybe it’s a little bit of a chicken or an egg kind of issue – does this enable them or they have enabled the compliance issue? Developers are taking to heart the fact that security is everyone’s responsibility, and the fact of the matter is it starts with them. Right?

    Nathen Harvey:           Absolutely. Alan, we’ve seen similar things in the past. Look at QA teams, where developers have said, “You know what? We’re going to start doing test-driven development. We’re going to adopt some of those practices.” And the QA teams get nervous, “That’s my job.” The problem with having it be someone else’s job is you’re not going to do it. You’re not going to be concerned with it.

    So, really, just like our QA professionals are now partnering with the devs, the security professionals and compliance officers are now partnering with the development teams. Frankly, that’s what dev-ops is all about. It’s about this working together towards those common goals and getting there as quickly as we can.

    Alan Shimel:                Yeah, absolutely. And it’s good. It’s good on so many levels to have the security team integrated with the devs, to be working closely with both dev and ops, dev-ops, and making it happen because, frankly, that’s what attracted me to dev-ops to begin with, was the promise of being able to do that instead of being the appendage at the end of the Rube Goldberg kind of –

    Nathen Harvey:           Absolutely. Alan, what you’re really looking at there is we’re talking about a partnership. So there are some cultural or some workflow changes, some partnering that we have to do across the organization. The thing that helps enable that also is the tooling. The tooling definitely matters and the two, culture and tooling, are there to reinforce one another.

    So with Chef, we have a new open source language called InSpec and that’s the tooling that allows the developers to actually write these compliance controls, execute them locally. Frankly, it allows them to write them in a way that’s delightful, in a way that a developer understands, that a business analyst can look at those tasks and understand exactly what’s happening.

    Then with Chef compliance we also introduce those same compliance controls into our own scanner capability, where you can scan against your production environment, find vulnerabilities, go back into your automation code, remediate those, and watch that remediation happen across the entirety of your pipeline.

    Alan Shimel:                Fantastic. Nathen, as I had told you earlier, before we started recording, our time is limited, but for folks who maybe want to find out more about compliance scanning, more about Chef’s capabilities in this area, where can they go to get more?

    Nathen Harvey:           For sure the place that they can go is www.chef.io/compliance. Again, I just want to stress that the scanning capabilities are absolutely important, but really what we need to do is shift our mindset and think about: how do we start writing tests for those controls and do those early on in the process? Not that scanning should be an afterthought, but we really do need to focus on that beginning stages of our development process.

    Alan Shimel:                And automation, automating that is key. Nathen, we’re almost out of time here. Unfortunately, it always goes too quickly. But I wanted to ask you one last question, which we usually ask our guests here on DevOps Chat. That is one book, if you had to recommend one book to our listeners that they should read maybe over the summer or in the near future, what book would that be?

    Nathen Harvey:           I would recommend Lean Enterprise: How High Performance Organizations Innovate at Scale. It’s a book by Jez Humble, Joanne Molesky, and Barry O’Reilly.

    Alan Shimel:                It’s actually on my bookshelf. Cool. I love it when someone suggests a book I’ve read actually. Very cool, Nathen, and it is a great book. Jez’ Lean Enterprise book is great as of course is the Continuous Delivery book.

    Anyway, Nathen, we’re about out of time here. So I wanted to thank you for being our guest on DevOps Chat. Continued success with your globetrotting VP of Community Development role at Chef, and continued success to Chef in general there. It’s one of our favorite companies in dev-ops and we love what they’re doing.

    Nathen Harvey:           All right.

    Alan Shimel:                And maybe we’ll get you back on again soon.

    Nathen Harvey:           Yeah, that sounds great. Thanks so much, Alan.

    Alan Shimel:    Okay. This is Alan Shimel with Nathen Harvey, VP Community Development of Chef for DevOps Chat. Thanks and we’ll see you next time.

  • Development Tools Sprawl and the Impact of Open Source: The Herding Kittens Survey

    Development Tools Sprawl and the Impact of Open Source: The Herding Kittens Survey

    devopsy.kinsta.cloud and Automic partnered up to conduct a survey back in February and March of several hundred respondents regarding their use of development tools, their use of Open Source and their rate of change. The survey report entitled: Managing Your DevOps Tool Chest, The Complexity of Herding Kittens is available from Automic here (fyi, registration is required to download the report).

    Scott Wilson of Automic and I already conducted a webinar where we took a deep dive on the findings of the survey. You can access the slides and recording of that webinar here (FYI, this is also behind a registration wall).

    If you take a moment to study the analysis you will see what I think are some interesting things in this survey. One is that we had two basic groups who answered. One was made up of our devopsy.kinsta.cloud readers who tend to be DevOps adopters. The other was a more General IT group. There was some stark differences between the two groups. None was bigger than frequency of release and how often you would like to release code. Talk about polar opposites!

    Another interesting filter we applied was by size of organization. The biggest differences when comparing startup smaller organizations to large enterprises was the amount of tools and coding languages they used. Of course larger organizations used more than smaller ones. But the starker difference was in open source usage. Smaller organizations used a much greater percentage of open source tools than larger enterprises.

    Finally we also looked at geographical region and industry vertical to draw distinctions. You can read the report and listen to the webinar to to get all of the details on this and more. I highly recommend you download the report and take a look. Also if you can spare some time to listen to the webinar I think you will pick up some great insights.