devopsy.kinsta.cloud

Category: Podcasts

  • DevOps Chat: Dave West, CEO Scrum.Org

    DevOps Chat: Dave West, CEO Scrum.Org

    I recently met Dave West, CEO of Scrum.org. While not one of the founders of Scrum.org, West is the CEO and product owner at Scrum.org. Dave and I spoke a bit what is happening with Scrum.org and how it interacts with DevOps. If you are interested in Agile, DevOps and Scrum, this is a good DevOps Chat to listen to.

    Here is the SoundCloud audio and the transcript is below:

    Here is the transcript of our conversation:

    Alan Shimel: Hi, Alan Shimel here for another DevOps Chat. And this DevOps Chat is with Dave West , product owner and CEO of Scrum.org.

    Dave, welcome to DevOps Chats.

    West: Oh, thanks for inviting me Alan.

    Shimel: Thank you. So, Dave, I’m going to make a wild bet that most of our audience at least is familiar with Agile and Scrum.  But maybe some of them aren’t and maybe there are even some who aren’t familiar with Scrum.org and the role it plays within the Agile community. So why don’t we do a quick level-set of Scrum.org and how it relates to Agile and Scrum.

    West: Yeah, thanks, Alan.

    Yeah, probably. It’s definitely a confusing fragmented place, the Agile community. So Scrum.org is an organization—mission-based organization created by Ken Schwaber, one of the co-creators of Scrum. Him and Jeff created Scrum—interestingly, in the building that I’m talking to you from, over 21 years ago. The outing 21-year anniversary is in October.  Maybe it’s October the 19th. Interestingly. So they created Scrum.

    Scrum.org is an organization that Ken created to, basically, focus on improving the profession of software delivery. We do that with a very large, active community—I suppose not very large—of professional Scrum trainers. About 170 of those. We do that with assessments; training and assessments around the world.

    A significant number of people visit Scrum.org every day to either assess their knowledge or to connect up with a trainer or some training class. 

    Shimel: Sure.  And Dave, one of the interesting things about the different classes and courses, if you will, that Scrum.org offers is the—there’s different sort of—I forgot the exact word, but there’s different roles. Right? Within the Scrum training.

    West: Yeah, I must—what’s interesting, actually, Alan, is that particularly for this audience, one of the reasons why Scrum.org came into being was obviously, Ken created Scrum Alliance.

    He left Scrum Alliance because they wanted to focus on the world of work. And Scrum.org cares about software delivery, and that’s a very important distinction. And so our professional Scrum developer class is actually—focuses on the practices for doing done software. And when we mean, “done,” we don’t mean, “almost done.”  We don’t mean, “Oh, well, it’s kinda done with me.”  We mean done. Meaning, potentially shippable. And when we mean potentially shippable, we don’t mean potentially shippable because operations haven’t looked at it yet, and that’s the potential. We mean, that the product owner can flip a switch and it’s live in the masses.

    So ultimately, this technology focused class, PSD, is one of the reasons why Scrum.org came into fruition, and obviously Scrum Master Product Toner—that the three roles of Scrum—we have classes for all of those different roles, and they’re very team-based. And so that potentially you could have more than two roles in the same class, as well with our team-based classes.

    So yeah, we definitely—we’re trying to improve the profession, Alan. So we have to provide training and certification. Third-party, validated certification on that profession and those professional skills.

    Shimel: Got it. So, Agile’s been around now for a number of years and at this point, I don’t think there’s any doubt that it’s gone mainstream, obviously and has a tremendous impact across the entire software development world spectrum. But, Dave, specifically for as it relates to DevOps, often people say, “Well how do those work together?” Right? I’ve heard people say—actually devopsy.kinsta.cloud before I had started it as a site, when it was just a blog, sort of said, “Picks up where Agile leaves off.” But I don’t think that’s necessarily true. I don’t think it was true then, it’s certainly not true now. How do you describe—let’s put it that way: How do you describe that relationship?

    West: It’s an interesting one.  In fact, recently I was on a presentation with Ken Schwaber. It was a DevOps presentation at a DevOps organization and event and Ken and I were talking about DevOps and Ken’s perspective is very interesting and I think it sort of sums up the original signatures of the Agile manifesto’s perspective on it.

    Ultimately, they believe and he believes in particular that we needed DevOps because nobody really got Agile. And it’s interesting because when they—when the Agile manifesto was signed one of the key terms was, “working software.” Working software. The 12 principles—working software frequently, delivering working software. That word, that phrase, “working software,” is frequently described in the manifesto.

    Scrum focuses on it now. Many people get Scrum wrong because frankly, and I don’t know if you see this, Alan, and if other people have said this to you but, what most people do is they take Scrum and then try to put it into a Waterfall life cycle.

    Shimel: Yeah. 

    West: So they sort of create these things around Scrum and particularly in the DevOps world, the bits after—they have this whole set of processes after the Scrum and hardening sprints.  They have a release train that goes through, you know; Scrum’s just a series of stations on the release train journey and it ends up in operations and the like.

    And so ultimately, Ken would argue that it’s just, unfortunately, people didn’t understand Agility or Scrum in particular and that’s what led to the DevOps movement.

    I have a slightly different view. I think that the Agile was very focused on at least getting testers and requirements people and the customer and the developers together in some way. And by that focus—and that focus was important to get to improve how we’re doing software—it highlighted that we actually need other people involved and that led to this sort of movement; combined with some technology changes like stuff around the cloud and the ability to self-provision and all that kind of stuff.

    So, it led to this sort of DevOps movement. I’m not sort of anti-DevOps. I think DevOps is an awesome set of ideas. I think people like Gene Kim and the Phoenix Project etc.—amazing stuff.  But ultimately, in my opinion, it’s all about improving the profession of software delivery and it’s all about Agile software and I see Scrum and a variety of other approaches really just being incomplete without the ideas of DevOps in them. And that’s certainly true of our PSD class. That’s certainly true of the message that we send to our customers. Sometimes they don’t like it when we say, “Okay, what does done mean to you?” and they say, “Tested.” And we say, “Not quite sure. There’s a few things after test.”

    Shimel: Correct.

    West: And they go, “Well, no.  There’s nothing after test to us. That’s when those ops guys get involved.”

    Shimel: Yeah.

    West: And they’re like, “Well, there might be a lot of—does ever defects come back into the process after test?” Well yeah, of course, you know, there’s – “And do ever customers have issues with it?” Oh yeah, and, “Do you ever get operations saying, ‘well we can’t get this to run on this environment?’” And do you ever say, “It works on my machine”?

    And all of those things get in the way.  All of those things that, whether you call them debt, whether you call them quality issues, get in the way of delivery and working software that amazes the customer, and getting that feedback.

    So DevOps is a great set of practices and ideas and a great movement than can make Agile even more successful.

    Shimel: Absolutely. I call those things “life,” by the way. But, you know, life gets in the way of the best-written software.

    So, a couple of things Dave. I have two specific questions I’d like to ask you.

    One is, you know one of the things that—maybe it’s been a double-edged sword for Agile/Scrum movement—but in my mind it certainly had so many positives, was the whole idea of the Agile manifesto, right? And sort of codifying if you will. What it is; the definition is. And then I think that leads to the ability to really nail down roles and training and methodologies.

    Well, as you know, in DevOps, there’s been a big resistance from even defining it officially. We never had a DevOps manifesto and there probably never will be one either. Do you view that as—let me contrast that with the Agile and Scrum experience— positive? Negative? Double-edged? Both ways? What do you think?

    West: It’s interesting because I think a lot about how you drive change into the world and obviously at Scrum I spend—at Scrum.org I spend a lot of time thinking about the success of Scrum. Scrum, as I said, turned 21 or turns 21. It currently can’t drink but in November it’s gonna be crazy.

    Shimel: Mm-hmm.

    West: In October, it turns 21 and I think about the success and Scrum is practiced—I was talking to Ken this morning, and it’s funny because I said, “You do realize Ken that over a million people every day, do a daily Scrum.”

    Shimel: Yep.

    West: He said, “Wow, that’s a lot, isn’t it?” And it’s practice.

    Now, whether it’s practice—well, Alan—whether they’re doing it right and whether that actually is good, and lots of questions.  But ultimately, you can’t argue with the success of Agile and Scrum. And you can’t argue with its—and so I often think about what makes it successful and is it the manifesto? I think in part it is.

    I think it provides a set of principles and ideas that sort-of provide the social system as it were to the practices that Scrum encourages. And I think things like the Agile conferences and that continues—you provide a place for people to talk about it, which is good. I also think there needs to be a very effective commercial model and when I mean commercial model—a commercial model around driving, making people go to pay their mortgage and put food on their table using Scrum to help them do that. Whether that’s through training, certification, writing books—there’s over a hundred books with Scrum in their title just on Amazon. There’s like 130 and I got bored counting. And I didn’t count the foreign books obviously because I’m English, and that’s against my principles.

    But what’s interesting is that—so that commercial model is incredibly important and I think also ownership. I think the one thing that we’ve found with the Scrum community is that Ken and Jeff have continued to really push it and drive it and that ownership connected with certification, assessments, training, books, community—strong community—simplicity, because I think that’s a very important idea that comes out, have allowed Scrum to be successful.

    So, I look at DevOps. And DevOps is very fragmented—even more-so than Agile. Vendors tend to have taken it and defined it to their own needs. You know, the Scrum Guide is the definitive definition of Scrum. It’s about 16 pages. It’s translated into over 40 languages and you can’t—it tells you what Scrum is. And if anybody says, “Oh, well, to do Scrum you have to do Jira and Jira does this,” I’m just using Jira as an example; it’s an awesome tool. No, actually, no, Scrum says this and yes, you can have ways of doing the daily Scrum with your Jira board and whatever, that’s cool. But Scrum is Scrum. And the problem is we’ve got all these vendors defining DevOps to be what they want it to be. To sell some software. All good—I mean, fair play to them. I would do exactly the same.

    So, without that sort of body of knowledge, without people sort of saying, “Hang on a minute,” sort of leadership, clear leadership. Without a commercial model that’s driving DevOps into organizations, or Scrum into organizations is another example. I think you have some significant challenges. I’m not sure they need a manifesto Alan, I’m not sure they need—but they definitely need a definitive what it is, however that’s done. It could be done with a guide. Or it could be done with something else. And I think that it needs that sort of leadership as well. And Gene is awesome—Gene Kim and the guys. There’s some really good thought leaders, but again, they’re fragmented as well.

    Shimel: Sure.

    West: Is Jez Humble a thought leader in it? Yes, he is. But he talks about continuous delivery. He doesn’t really talk about DevOps and ….  That’s challenging.

    Shimel: Yeah, I know, Dave. So just, my 2 cents on it is, it’s very much a two-edged sword. In some ways, it’s been its biggest help and in some ways its biggest hindrance.

    I’m just back from London with Gene Kim’s DevOps Enterprise Summit, London took place and I interviewed all the speakers there and we did a ton of video and speaking with people and what’s interesting is by its lack of definition, the DevOps way if you will—the DevOps way is whatever you—sounds like something out of the Dune movie, the Weirding Ways. But, the DevOps ways are that patterns or whatever you want to call it is moving even beyond Dev and Ops. Dev and Ops working together to encompass security, QA, other parts of the IT stack and even beyond the IT stack, we heard stories of marketing and biz and HR even, teams that are starting to use Kanban and stuff like this because it helps them. I mean, look: Here at devopsy.kinsta.cloud, we do a 9:30 standup meeting around the table every day, right?

    And you know, I don’t consider us a software company, per se, or that we’re developing software but the entire on-prime staff is in that meeting. And we do our check-in and so forth. But that being said, that lack of definition has almost, I think enabled DevOps to move beyond pure Dev and Ops. But you speak to—you talked about Jez Humble—you speak John Willis for instance; another DevOps, kind of, personality who’s been around a while and John says, “No, I’m more of a purist.” DevOps is about Dev and Ops. Right? I don’t buy into that whole kind of thing, but that all being said, that kind of helped it not having that definition but to your point, it hindered it in that you can’t really put your thumb on it and it’s nebulous and a lot of people say that. Right?

    West: Yeah.

    Shimel: And it’s this—

    [Crosstalk]

    West: It might be good and it might be bad. What ultimately all of us are striving for is the values of the Agile manifesto.

    Shimel: Sure.

    West: And DevOps is doing that as well. It’s about delivering done. And it’s about breaking up batch sizes to smaller increments of value driven by hypotheses or experiments or ideas and it’s about delivering practices which the DevOps community have in spades of actually being able to do that.

    Shimel: Yep.

    West: So if you have the principle of delivering software frequently, and observing it’s use by customers—if that’s a principle that’s driving your delivery mechanism then it’s crucial that you get that transparency. You instrument etc. You do it frequently, you get the batch size smaller, etc. Those principles—and they all trace back to that ultimate set of Agile ideas—and those ideas are basically all in response to the fact that we’re working in environments where there’s a large amount of unknown. Whether that be technology, whether that be business. And those unknowns require us to work in a different way.

    The traditional, very efficient, big silos, clear hand-off, control points, get in the way when there’s a large amount of unknown and where variability is the currency of the entire operation. And when you do that, you have to work in different ways. And all those practices, make it so much better. And I think that’s what we need to concentrate on.

    [Crosstalk]

    Shimel: Those are the universals. Dave, I think that’s universal. Yeah.

    West: And I think that’s what—and I think, to be frank, most of the—I know Gene definitely is very, very conscious of that. Obviously, protecting his brand as he needs to. Yeah, I just love the fact that all these vendors positioned DevOps for their own means. Yeah, so, I don’t know. What I do know is that Agile isn’t versus DevOps and Scrum.

    [Crosstalk]

    Shimel: Certainly not.

    West: And Scrum isn’t versus DevOps and we need to stop thinking about the Sprint Review as a phase gate to release to operations. And we need to think about it as a mechanism for learning, inspect and adapt. Learning at the boundary of the Sprint. So, we’ve got this chunk of work—two weeks of work—we’ve delivered some software and production hopefully during that two weeks of work. Operations is part of our Dev Team. There just—whether that be directly or indirectly. Obviously, we know that if it’s indirect, cues are bad because that reduces Agility.

    So, we need self-serve, we need automation that allows them not to be a bottleneck. We need to be able to get RVMs when we need RVMS, etc. And we need mechanisms in place that get rid of all the overheads to the delivery teams. And I say delivery, not development. It’s everybody that’s needed. We need some mechanisms in place that get rid of the inhibitors to delivering working software as frequently as we need to, to get that inspection working for our business.

    That’s what ultimately we need to do and sometimes DevOps—it’s a great movement. Sometimes, it gets in the way because we go, “Oh, wow now I’m DevOps, not Scrum.” And I don’t give a diddly if you’re Scrum or DevOps. All I care about is delivering frequently to learn so that I can improve and deliver value faster to our customers.

    Shimel: Got it. Well, Dave. I hate to do this to you, but we’ve run over schedule here. But it happens. I told you before we got on, that it goes quick. We’re well past it at this point. But, one last question that I like to always ask guests, and that is: Can you recommend one book to our audience that they should read?

    West: Yeah, Alan, I don’t know if I can recommend a book to read, but I can tell you the book I’m currently reading.

    Shimel: Fair enough.

    West: And it’s interesting because there’s lots of great books, obviously. A wise man once said to me, “I don’t mind if you read my books, as long as you buy them.” So there’s lots of great books, but I like the book I’m reading at the moment. It’s called, “Turn the Ship Around.” And it’s a really interesting—it’s a true story of this—basically, this guy that’s running this nuclear submarine by this gentleman called David Marquet. And it’s really very interesting because a nuclear submarine you would think has got as much in common with a software delivery project as—I don’t know—as something that doesn’t have much in common with something else.

    But ultimately, you learn a lot about how you can get autonomy, get self-direction in your teams, how you can keep people happy when you’re in this, sort of, steel coffin under the water when you’re not talking to your loved ones for thousands of hours because you’ve got nuclear weapons on, and you have to be hidden somewhere in the Atlantic or Pacific. And it’s a very interesting book and I’m about halfway through, so I can’t tell you if it’s the best book in the world but I can tell you the first half has started very, very well. “Turn the Ship Around.”

    Shimel: Got it. Sounds like a good and I will see if we get any feedback from the audience.

    Well, Dave, so we totally blew through this, but it’s okay. It was a great interview and I hope people enjoyed listening to you continue success with Scrum.org and maybe we could have you back on at some point; we could continue this discussion.

    West: I’d love to Alan. Love to. It’s been an absolute pleasure.

    Shimel: Okay. Dave West, product owner, CEO of Scrum.org, thanks for being this episode’s guest of devopsy.kinsta.cloud

    This is Alan Shimel for devopsy.kinsta.cloud.

  • 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.

  • 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.

  • 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Alan Shimel:                Really?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    DevOps Chat: Software Lifecycle Management with Michael Azoff, Ovum

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

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

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

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

    Here is the transcript of our conversation:

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

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

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

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

    Alan Shimel:                Fantastic –

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

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

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

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

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

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

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

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

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

    Alan Shimel:                Sounds pretty comprehensive.

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

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

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

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

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

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

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

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

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

    Michael Azoff:             Thanks, Alan, for inviting me.

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

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

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

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

     

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

     

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

     

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

    Pete:                             Yeah. Thanks for having me.

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

    Chris:                           Thanks so much.

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

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

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

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

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

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

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

    Alan:                             Okay. Excellent. And Peter?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Alan:                             Yeah.

    Alan:                             Exactly.

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

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

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

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

    Alan:                             Yeah.

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

    Chris:                           Right.

    Alan:                             Perfect. Chris, how about you?

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

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

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

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

  • DevOps Chat: Dan Berg on Open Technologies and the Open Enterprise

    DevOps Chat: Dan Berg on Open Technologies and the Open Enterprise

    I had a chance to speak with Dan Berg, distinguished engineer at IBM. Dan and I discussed open technologies, open enterprise and open tool chains. A whole lot of open there.  We also talked about how open technologies will be part of the upcoming IBM InterConnect event.  Below is the stream of our conversation and below that is the transcript if you would like to read along.

    Enjoy!

    Alan Shimel:                Hi everyone, this is Alan Shimel, Editor and Chief of devopsy.kinsta.cloud, and welcome to another DevOps chat. Today, our guest on DevOps chat is Dan Berg of IBM, and we will be talking about DevOps and open technologies. Dan, welcome to DevOps chat.

    Dan Berg:                   Thank you, Alan.

    Alan Shimel:                So Dan, before we jump into the whole open technologies, open enterprise subject, can you give our listeners just a little bit of background of who you are, what you do and why you’re here today?

    Dan Berg:                   Sure. So as you pointed out, my name is Dan Berg. I do work for IBM. I’m a distinguished engineer, working in our cloud platform organization, which fundamentally means I’m responsible for working with a set of very energetic teams that are building out services in our cloud foundation. So the IBM cloud platform, specifically in IBM Bluemix, things like our container service, log-in and monitoring services, several DevOps based services. So services such as things like we call active deploy that help deploy microservices within a cloud architecture. So I do a lot in that space, helping the teams identify the strategy and the architecture that we’ll use. I’m also very much involved in our DevOps organization within IBM cloud, focusing on both cloud native applications, as well as hybrid cloud applications.

    Alan Shimel:                That’s fantastic, and Dan, you know, we talk about DevOps, and certainly when we talk about cloud, one could say we’d have no DevOps or no cloud without open source. What do you think about that statement?

    Dan Berg:                   I think that’s a pretty profound statement. Open source is a strong component of cloud strategies.

    I think almost all customers are looking at cloud as a direction. I talk to a lot of our customers, and I can’t say any of them that do not have a cloud strategy or at least pursuing a cloud strategy.

    And one of the areas that comes up quite often is this notion of being able to have the flexibility of choice. I want to be able to choose my cloud provider and I might want multiple cloud providers.

    And the only way to really achieve that is to have an open community and open standards that allow you to develop your workloads, develop your applications in such a way that you can move them from one provider to the next in their run, as you would expect them across multiple providers.

    And as I pointed out, you’re not gonna get that unless you’re focusing on a strong open community that is driving open standards.

    Alan Shimel:                Yeah, you know Dan, so I’m old and I remember when I first got into IT and technology, there was a time where there was tremendous pushback about open sourcing the enterprise.

    We’ve all read the books and we’ve listened to Richard Stallman and the book is escaping me now. What’s the great book about open source? Something about the bazaar and the – oh, whatever.

    Gosh, I’ll find it but the more important thing is you know we’ve – and what was the pushback?

    How can the enterprise rely on open source without support, without vetting and all of that?

    And really it’s been companies like IBM and dare I say, even Microsoft now that have kind of helped pave the way for open source into the enterprise. What do you – what’s your thoughts on that?

    Dan Berg:                   Well, so it’s interesting to see how the open source has evolved, how developing in the open has really changed the way in which developers learn, and how they adopt technologies.

    You first and foremost look to the open communities as a way to understand new technologies and to join a community in which those technologies are evolving and you’re right.

    Enterprises often look at or have in the past looked at open source as, okay, that’s cheap software that people are doing on the side. They’re not part of any company. How can we trust this?

    Is it enterprise ready? We’d better not touch it. Right, we’d better develop our own. I think that mentality has changed dramatically for a number of reasons.

    One, the communities have become extremely large. I mean look at things like the open stack community or the cloud foundry community, the Docker community.

    These communities have established a base set of users and contributors, and have grown substantially over the last several years, and what they’re developing is being developed with an enterprise mindset. I mean it’s not just for kicking the tires or playing around.

    We’re developing enterprise grade solutions in the open, and the reason why it’s being done in the open is because with the community around these initiatives, you end up getting more input from various stakeholders and ultimately at the end, you get better solutions that cater to a larger set of stakeholders.

    I know within IBM, I mean we’ve been developing in the open for many years. I can remember way back, 15 years ago, working in the open.

    While it may be difficult initially, when you’re thinking oh, I’ve got to work with a community of people and get agreement, that is true to some degree.

    But what you find is that as more people start working together and collaborating across the globe on a set of technologies, an open set of technologies, it actually picks up pace and you can innovate much faster, because you just have a larger pool of resources and developers working on that code base.

    And that’s what we’ve been seeing, and adopting that back into an enterprise and using it has become easier because you’ve got enterprises like IBM, like Microsoft, like others that are contributing to these open communities and ensuring that enterprise requirements are added into those code bases, so that they can be consumed by an enterprise.

    So it is shifting. I think more and more, enterprises are adopting open source capabilities because of the innovation and the enterprise grade quality that’s coming out of those communities.

    Alan Shimel:                Absolutely. By the way, Dan, the book was The Cathedral and the Bazaar.

    Dan Berg:                   Yeah.

    Alan Shimel:                By Eric Raymond, and I’m sure you read it too. It’s – you know what, at this point, I’m ashamed to tell you. It’s like 15, 20 years old but, whatever, it’s still good.

    So Dan, let me pivot a little bit with you and let’s quickly turn. This month we have the IBM interconnect show, which is sort of IBM’s big cloud in mobile and I like to say DevOps event as well.

    And the open enterprise and open source is front and center, and rightfully so, in light of what you’ve just told us.

    What can you highlight for us a little bit maybe about the open source, open enterprise at Interconnect this year?

    Dan Berg:                   Yeah, so there’s gonna be a number of exciting things. I mean we do really drive the notion of open source and open technologies.

    We’re gonna be discussing obviously some of our core initiatives around open stack, around node and JavaScript, Docker as well.

    We’ve got a number of exciting sessions and activities that we’re driving within those communities.

    The open container initiative, another big one that we’re involved with and discussing the direction that we’re helping to forge in that community to drive where we see containers going.

    So that’s Docker based containers and other containers, really driving a stronger community around the container movement. Even around DevOps, the great, great thing that we’ll be showing off there is some of the work that we’ve done with the IBM garage method.

    So it’s an open set of processes and practices that we announced late last year, and then moving into this year in the envelope a little bit further, and what we’re doing is associating with the practices, a set of tools.

    And these tools are obviously some tools that we provide, services that we provide, but a lot of them are open tools as well that are being developed and made available in the open communities.

    But one of the exciting things in this area that we’re driving is something we call the open tool chain, and open tool chains are a set of capabilities that allow organizations to define their best of breed practices and DevOps capabilities in a tool chain.

    An integrated set of practices and tools that can be instantiated by other parties.

    So we’re pretty excited about that initiative. It’s still early days but we do see the potential there and the flexibility that’s being achieved by bringing together these open technologies into a unified tool chain that drives cloud native deployment and delivery mechanisms.

    So we’re very excited; lots going on in these communities and we’re really excited about sharing that information at Interconnect in about two and a half, three weeks.

    Alan Shimel:                Absolutely, you know, Dan, I think I might have been out with you in San Francisco when they announced the open garage method at – I forgot what conference it was but in any event, it was a DevOps enterprise summit.

    Dan Berg:                   That’s right.

    Alan Shimel:                As you mentioned.

    Dan Berg:                   That’s right.

    Alan Shimel:                And you know, to me that was a little different, especially for an IBM in that it wasn’t an open source project. Right, it wasn’t a particular tool.

    This was really more of an open methodology with tools tied into it and you talk about a supply chain.

    It is a sort of that software supply chain where the software or the app you’re developing, not all of it is going to be open source.

    But there are open source components that make it easier for us to develop apps in real time continuously, with continuous delivery and integration, and all of this goodness we see in DevOps.

    And to me that was sort of the power of the garage method, right, was this software supply chain, if you will, with open source components, making up a lot of it, wrapped around IBM’s experience and know-how in bringing this together. I think it’s powerful.

    Dan Berg:                I definitely agree, and as I pointed out it’s still early days but it’s showing the promise. I mean we all know how difficult it is sometimes to piecemeal together your delivery tool chain with the various open source tools as well as third party vendor specific tools.

    It can be quite complex and what’s really nice about the open tool chain is it takes some of that complexity out of your way and really helps you focus in on your key initiative, and that is deliver high quality code as quickly as possible.

    So I’m really excited about it. It does build upon some of our core technologies, but I’m really excited about how it brings in some of these key open technologies and open communities to drive better DevOps experience overall.

    Alan Shimel:                Yeah, agreed. You know, Dan, unfortunately we’re coming up on the clock but this is – you know, the whole subject of open source of software supply chains, of the open enterprise.

    And how enterprises are incorporating open source components into their supply chain is one that fascinates me and one that I think you’ll see more of on devopsy.kinsta.cloud, as well as it sounds like quite a bit of it at Interconnect later this month.

    Dan Berg:                   Absolutely, and if anyone’s gonna be out at Interconnect, definitely look me up. You can find me. I’m doing a number of different sessions, and you can grab me on Twitter at DanCBerg.

    Alan Shimel:                Yeah, well and they could also look for you on the Interconnect site, Dan and probably search by speaker.

    Dan Berg:                   Absolutely.

    Alan Shimel:                Just we don’t have any time but which of your talks or sessions are you most looking forward to?

    Dan Berg:                   Oh gosh, there’s a number of sessions but there is one, and I’d have to look. I forget the name but it’s a DevOps panel that I’m looking forward to.

    And there’s a number of us on there including myself and Gene Kim are gonna be on the panel. I believe it’s on Tuesday, if I’m not mistaken.

    Alan Shimel:                I believe that would be my panel.

    Dan Berg:                   I’ll have to look in my —

    Alan Shimel:                What does DevOps look like in the next five years?

    Dan Berg:                   Ah, that’s right, it’s yours

    Alan Shimel:                Thanks for the plug, Dan

    Dan Berg:                   Not a problem.

    Alan Shimel:                I welcome people to come out and check it out. We’re looking forward to a great panel. What a way to end our conversation.

    Dan Berg, distinguished engineer for IBM, thank you so much for joining us today on DevOps chat, and I’ll see you later this month at Interconnect.

    Dan Berg:                   Absolutely, looking forward to it.

    Alan Shimel:    Okay, bye bye. This is Alan Shimel for devopsy.kinsta.cloud and we’ll see you on another DevOps chat.