devopsy.kinsta.cloud

Category: DevOps Chats

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.

July 15, 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.

July 6, 2016
DevOps Chat: Habitat by Chef with Julian Dunn

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

July 6, 2016
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.

June 9, 2016
DevOps Chat: Gene Kim, DevOps Enterprise Summit London 2016

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

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

Enjoy!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Alan Shimel:                Right.

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

Alan Shimel:                Go ahead.

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

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

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

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

Gene Kim:                   Right.

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

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

Alan Shimel:                Yep.

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

Alan Shimel:                Yes.

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

Alan Shimel:                Yeah.

Gene Kim:                   I love that Hiscox story.

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

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

Alan Shimel:                Yes.

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

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

Gene Kim:                   I love them both.

Alan Shimel:                I’m sorry what, Gene?

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

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

Alan Shimel:                Yes.

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

Alan Shimel:                Yeah.

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

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

Gene Kim:                   Yeah.

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

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

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

Alan Shimel:                Excellent.

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

Alan Shimel:                What a great metric.

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

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

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

Alan Shimel:                Yep.

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

Alan Shimel:                Absolutely.

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

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

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

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

May 18, 2016
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.

May 3, 2016
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:
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.
April 27, 2016
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.

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

April 15, 2016
DevOps Chat: Rachel Reinitz, IBM Bluemix Garage Method

In advance of InterConnect next week in Las Vegas, I had a chance to sit down with Rachel Reinitz,Distinguished Engineer & CTO of IBM Bluemix Garage. I have met Rachel several times and it is always a pleasure to catch up on all of the innovative things her and her team are doing with Bluemix Garage. In this conversation, Rachel and I spoke about open technologies which is a focus for us this month, as well as a big focus of the Bluemix Garage method. We also spoke about “innovating like a startup, while scaling for the enterprise”. To learn more about the IBM Bluemix Garage Method, please visit: https://www.ibm.com/devops/method/

You can find our conversation below and a transcript of it below that. Enjoy!

Alan Shimel:                Hi, everyone. Alan Shimel, devopsy.kinsta.cloud here for another DevOps chat. Today’s special guest is Rachel Reinitz of IBM. Rachel, welcome.

Rachel Reinitz:            Thanks, Alan. It’s always nice to be talking with you.

Alan Shimel:                Yes, actually I think the last time we spoke was DevOps Enterprise Summit in San Francisco. And Rachel, for our listeners who may not be familiar or didn’t get a chance to see our video which is on YouTube from DevOps Enterprise Summit, why don’t you tell them a little bit about yourself.

Rachel Reinitz:            So I am a distinguished engineer at IBM and I co-founded and I’m the technical lead for the IBM Bluemix Garages.

Alan Shimel:                Excellent. And you know, Rachel, there’s been a lot of announcements and news and developments, no pun intended, coming out of the IBM Bluemix Garages that some in our audience may not be familiar with. So give us some of the highlights. First of all, what is the IBM Bluemix Garage? And what’s happening with it?

Rachel Reinitz:            So we are a consultancy within IBM. We work with customers making them successful in adopting Bluemix. And we are unique in that we are housed in startup communities. We work with both startup customers through to enterprise customers. And really what we work on is taking an idea, a problem or a concept and applying IBM design thinking, lean startup, extreme programming, DevOps to go from that idea to the definition of a minimal viable product and then onto building it and getting it out there and testing it out with users, testing the business hypotheses, all the really good DevOps practices and utilizing Bluemix which also gives us a lot of acceleration because of the kinds of services in the environment that we are in. So that’s what we do. It’s an exciting place to work and we have – and for clients to come into with designers, architects, developers. That’s pretty much what we do.

Alan Shimel:                Got it. Rachel, I was lucky enough to visit an IBM Bluemix Garage. I guess it was at the DevOps Enterprise Summit, around that time in San Francisco. And the best way I can explain it was it’s sort of a lab, kind of a living lab where experimentation was going on as well as education and development. And it seemed like a pretty cool environment. And both for enterprise as you mentioned, anything from enterprises on up to startups.

Rachel Reinitz:            That’s right. I think that that’s a good summary of it. We are in the startup community so we work with the startups there. And it really helps enterprises to innovate like startups, to get kind of out of their environment into our environment, a very collaborative space as you saw, when you were visiting right in the hardest heart community, we’ve actually, in some of environment news, we’ve moved to a different space still within the galvanized community in San Francisco, a bigger space, which is really exciting. We just had a little party there. And we have other locations. We are in Toronto and in London and we have a location in Nice. Each one is in a different kind of startup community. And we are working on Melbourne. So you’ll have to come investigate some of our other locations.

Alan Shimel:                Absolutely. We are actually doing a series of roadshows, one of which will be in London in April. We’d love to get some of the IBM Bluemix Garage folks at that. But we will talk off-line. Rachel, one of the reasons I invited you on was this month on devopsy.kinsta.cloud, we are really focusing on what we call the open technologies and open enterprise. And by that we don’t mean just open source software, though certainly open source software is part of it. But there’s more to open then software, isn’t there?

Rachel Reinitz:            Yeah, I agree. I think that’s knowledge sharing is a big part of open, sharing different kinds of knowledge in different kinds of mediums. And I think where you’re going is to the fact that we’ve now taken what we’ve been taking in the Garage and actually merged it with what we’ve been doing in open source and DevOps Transformation within IBM and we published that as the IBM Bluemix Garage method which is out there in public, open for people to use. And we’re also looking for contributions.

Alan Shimel:                Absolutely. And it is open, right? The whole methodology, if you will, is open. And I happen to know only because I’ve spoken to you folks before, a lot of the tools you are using are open source tools, traditional open source software. But really, when we talk about the open garage method, as I’ve heard it referred to, it’s open through and through, if you will, right? It truly is open technology.

Rachel Reinitz:            Yes. So it’s taking the lessons that we’ve been learning, it’s providing prescriptive paths and recommendations and that crosses from our software to what we are doing in the open community and open source, open-source testing tools, third-party tools. It’s what we find is working in projects that we are doing and recommendations around specific kinds of applications like a mobile application. What do we recommend? What did we learn and are sharing those learnings as you were saying out in the open? How do you go about testing them, for example? What are your different options? Things like that.

Alan Shimel:                Fantastic. Rachel, how big is Bluemix a part of this garage method, though?

Rachel Reinitz:            It’s definitely a big part of it in terms of we think that using Bluemix and other IBM technologies is a way to really accelerate building these kinds of applications. But it’s not exclusive to that. So when we talk about innovative practices, when we talk about some of our toolchain, no, it could be used with other technologies. Obviously I think there’s a lot of good reasons to use it with Bluemix.

Alan Shimel:                Sure, sure. And again, you know what, Rachel? We may have some folks who perhaps aren’t even familiar with Bluemix, why don’t we quickly give them a level set. When we say Bluemix, what are we talking about?

Rachel Reinitz:            So Bluemix is IBM’s platform as a service. It exists in public which is then hosted in our data centers, our public data centers for software. We also have a dedicated version where we provide a managed single instance of that same capability. And then we have what we call local which can deploy onto your own systems behind your firewall. And Bluemix has multiple models for writing applications with Cloud Foundry containers and VMs. And it has a whole range of services. At last count, I think we were at about 140 and those are IBM services like our SQL DB which is a form of DB2. But it’s also third-party services like New Relic. And as I said, it runs Cloud Foundry, it runs open-source runtimes. You can bring your own runtimes. So there’s a lot of openness to it.

Alan Shimel:                Excellent, excellent. And Rachel, you mentioned IBM was looking to work with third-party partners around this open methodology, open-source. What kind of partners, what kind of contributions would you be looking for that you think makes sense?

Rachel Reinitz:            So we have the concept of an open toolchain where different technologies can be integrated, again, around solving a particular kind of problem like mobile. And our toolchain team works with different partners. So we are very open to partners coming in and saying hey, can we be part of the toolchain and talking about how you integrate? So for example Slack is part of what we talk about there. That’s one kind of integration. Another level of integration we have is in Bluemix itself. So we have third-party services there and we have a whole program for how a company that’s providing capability that would be of interest to developers can integrate into Bluemix and be part of our ecosystem.

Alan Shimel:                Got it, got it. And Rachel, believe it or not, we are coming up on the – I promised you it would be about 10 minutes. We are going to run a little over but I wanted to quickly pivot, if you will. Besides this month being open technologies on devopsy.kinsta.cloud, we are also featuring our coverage of the upcoming IBM Interconnect Conference in Las Vegas. And I would imagine, pardon me, I haven’t pre-checked; but I would imagine IBM’s Bluemix Garage is going to have a prominent place at Interconnect, correct?

Rachel Reinitz:            Yes, yes. I’m really excited about Interconnect. We have, in the expo area, we actually have basically a mini garage set up, even with a motorcycle, I’m told. And we basically take you through the journey with a focus on our innovation path and we are sitting right next door to our DevOps team who also support the method so you can come and see what we are doing in terms of serving your innovation process and we show code, of course, and delivery pipeline. And that if you want to get even deeper and know the different options, we have the DevOps booth right near us. We have customers coming and talking about the work they’ve been doing with the Bluemix Garage method. We have workshops where you can get into a roundtable and really dive into it. So there’s a ton of things going on at Interconnect around the method. And of course, I’m presenting, too.

Alan Shimel:                Really? What are you presenting on, Rachel?

Rachel Reinitz:            I’m presenting on the Garage and on the method. I’ll be speaking, I think it’s Monday at 6:00 PM and then there’s a variety of different sessions. And then most exciting is I have some of my clients presenting with us.

Alan Shimel:                Really? In case anybody listening is actually attending Interconnect as they very well might, can you give us – I don’t mean to put you on the spot, but can you tell us maybe customers and which sessions customers are talking at?

Rachel Reinitz:            I’d have to look up specific sessions but we have KS2 and ManualLife, clients I’ve worked with really closely. Those are a couple of the – oh, and we have Spigot which has a really interesting cloud sourcing platform. So those are some of the customers that are going to be speaking. And there’s maybe a couple others that are ready to be talked about yet.

Alan Shimel:                Fantastic. And of course, on the expo floor, people can actually get hands-on with the Garage for themselves and see what it’s about.

Rachel Reinitz:            Absolutely.

Alan Shimel:                And just again, in case anyone listening, Interconnect is February 21-25, I believe. And it’s at Mandalay Bay and MGM Grand in Las Vegas. Rachel, just one more question. What’s next?

Rachel Reinitz:            More. More services. More services coming on Bluemix. We just had some – there’s new analytics, there’s new Watson services. It’s more coming, more projects with clients, cool Internet of things kinds of projects, more garages in the future building up the ones we have. Lots is going on. And in the method, too. More tools in the method, more prescriptive paths.

Alan Shimel:                Do you think we will see a Bluemix Garage method 2.0?

Rachel Reinitz:            Not 2.0 because we continuously deliver.

Alan Shimel:                That’s exactly right. Good jump on the answer.

Rachel Reinitz:            We came out with our MVP at DevOps Enterprise and now we will be having, you’ll see a lot more in there for Interconnect. We will just keep on going.

Alan Shimel:                Fantastic. Rachel, we are way over time so I’m going to need to call it a day here. But Rachel Reinitz, distinguished engineer of IBM and sort of mother of IBM’s Bluemix Garage. Welcome. Or thank you for being on DevOps Chats today. Look forward to seeing you at Interconnect February 21 out in Vegas. And look forward to continuing development on the IBM Bluemix Garage and Garage method. Thanks for appearing today.

Rachel Reinitz:            Thanks, Alan.

February 17, 2016
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.

February 11, 2016