devopsy.kinsta.cloud

Category: DevOps Chats

DevOps Chat: Measuring DevOps Success with Steve Boone, UrbanCode

In this DevOps Chat we speak with Steve Boone, product owner and development manager for Urban Code Deploy. Now that DevOps is in practice at more organizations, measuring DevOps success is a question many are asking. Steve has helped hundreds of companies adopt, implement and scale their agile and DevOps practices as part of their digital transformation. Steve gives us some insights into how can you measure your DevOps success.

As usual the streaming audio of our chat is below. Following that is a transcript of our conversation to follow along.

Audio

Transcript

[su_pullquote align=”right”][su_custom_gallery source=”media: 117787″ width=”100″ height=”100″] Steve Boone
Steve Boone is a DevOps SME at IBM. He has helped hundreds of companies adopt, implement, and scale their agile best practices including CI, CD, Environment Provisioning, and Application Release Automation. Steve is currently the Product Owner & Development Manager for IBM UrbanCode Deploy.[/su_pullquote]

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. I’m happy to be joined today by Steve Boone. Steve is the Product Owner and Development Manager for IBM UrbanCode Deploy, one of the leading CI/CD solutions in the market. Steve, welcome to DevOps Chat—how are you?

Steve Boone: Doing great, Alan. Thank you so much for having me today.

Shimel: Great. Steve, I wanted to talk to you—well, about a couple of things today. But let’s focus in first on, I’m just back from another major conference, and once again I’m—not amazed, because by this point, it’s expected. But still, you know, going strong, the biggest thing we get, or the biggest feedback that I hear from organizations looking to do DevOps transformation is—hey, this all sounds great, it sounds really good, but how do we know, you know, first of all, how do we get started with our DevOps transformation, and then once we’re doing it, how do we know it’s working? Right? How do we measure the ROI, or even if we can’t get to a real ROI, how do we measure progress? What does success look like?

And I would imagine, you know, the guys at UrbanCode, the team at UrbanCode has been dealing with this for some time. What do you tell people?

Boone: Yeah, that’s a great question, and it’s—you know, I think it’s a little different for everyone. And when we start looking at measuring success and first finding out, you know, where do we start, a lot of times we’ll work with customers to identify, you know, what are your problematic areas? There’s a lot of aspects to DevOps, it’s not all CI/CD, there could be aspects of agile planning, there could be release management. There’s a number of different things that come into play.

So, we usually sit down and try to focus on, you know, where do you think your bottlenecks exist today, and then start to address those. But when we went to measure—and you know, you’re right, the allure of DevOps comes with all of this ROI promise, right, where if we do these things and we change our people and our process and our tools, we’re gonna be better off for it, the business is gonna be better off for it.

So, how do we then make sure that’s actually happening, right? That the time and energy that I’m putting into changing my processes are actually showing me that ROI.

So, what we’ve seen a shift in the industry towards is really starting to gather the different sets of metrics that are coming from, really, the end to end products that we’re dealing with in DevOps whether it’s your build tools, your testing tools to understand what I’ll all our key metrics. So, you know, if in fact we are capable of speeding up our delivery to our pipeline, we should be getting to market faster, right? So, we look at statistics like cycle time—how long does it take for an application or a release of application to go from dev to prod? And then we look at that data over time. Is it, in fact, improving? And if not, we want to identify other bottlenecks that are kinda holding that progress up.

So, if I look at a set of components that make up an application and I see that the majority of those components have a really good cycle time, you know, we’re only as fast as our weakest link. So, if the database component, for example, is routinely slower to get through QA than the rest of the component, that’s going to slow down our time to market and therefore gonna slow down our release.

And the beauty is, in turning on the flashlight, so to speak, so that you can see that data and actually do something with it, a lot of times we look at it and say, “Well, we know we have automation and therefore we know we’re going faster.” But that just might mean we’re going to QA faster or we’re going to dev faster. We want to make sure that we’re actually getting that ROI, so if we can set baselines with teams and say, “Hey, prior to doing this automation, it took you four months to get from dev to production out the door, right? This past release cycle we did it in three and a half months—great. What is that time savings? What does that time savings mean in cost?”

And, we’re starting to see a big trend within the industry of many different companies starting to put together products to start to track these. So, I think it’s a whole new area for us to focus on, and in hopes—what we’re trying to share with customers is that, look, not only are the changes in people and process that you’re making working, but the tooling is working, and hey, here are some areas where you can improve those processes.

Shimel: Yeah. So, Steve, obviously, I want to—you said a mouthful, there. [Laughter] But let me focus in on one thing you said that I want to re-emphasize to our audience, and that is, you know, DevOps is so much more than CI and CD, right? There’s config management, there’s APM—there’s a lot that goes into this umbrella term that we call DevOps, and it seems to be growing every day.

That being said, though—you know, I once heard someone describe DevOps is the symptom and CD is the cure. So, you know, I don’t want to minimize the importance of CI/CD, but you know, automation—there’s so much that goes into this equation or this term that we call DevOps. And I think that’s—you know, Steve, it’s almost like it’s its greatest asset but it’s also its greatest liability, you know what I’m saying?

Boone: Yeah, there absolutely is. I think that a lot of times, we definitely see, when people are talking DevOps, their focus tends to be on CI/CD. And I think that’s because, you know, out of the gate, especially if you’re just starting off, it’s kind of your biggest bang for your buck, right? You can get a lot of fast return on investment just by improving your processes and automating them and making them consistent.

As we see teams mature, and as they transition into a more Enterprise wide DevOps solution, then we start to see—well, where are the real boundaries in my organization, right? Is it, we see a growing trend where app dev teams are focusing on automation, but there’s a whole different silo in infrastructure, you know? So, an app dev team wants to request an environment to do some testing in—they have automation, and the tools that they have for automation could easily provision that environment. But the business dictates that that’s the infrastructure’s just, and they have a completely different set of tools that they use for that, right?

And so now we get into this challenge of really continuing to try to break down these barriers to make sure that these assets and tools that are out there can work together, and that there’s clear cut guidelines on that.

So, yeah, I think it is a blessing and a curse, right? Because when we start thinking about DevOps, everybody wants that—you know, we’re a culture of having that instant gratification. So, it’s nice that we can get that with deployment automation and build automation and test automation. But we need to be looking ahead to the future, which is gonna be—hey, I’m gonna provision these things on demand and make these environments available to my teams, and today we use Amazon for that. What happens if, six months from now, we have to change and we need to support Azure or Google or SoftLayer or Bluemix, right? We need portability, we need full stack provisioning and config management on that.

And that’s—I think that’s something that, a lot of times, people just starting out, they don’t look too far ahead. And my suggestion to folks is—hey, it’s okay to take that first step. You should be cautious about the first step, but keep in mind where you wanna be two years from now, three years from now, five years from now. What’s your DevOps end goal?

Shimel: Yeah. You know what? So, Steve, I think that might be the first question we need to—especially for consultants out there who may be listening to this. You know, whether you work for an IBM or a small consultancy, I think that has to be the first question. You know, people come and say, “I want to do DevOps.” You gotta ask them, what’s the end goal, here? What’s the end game? Why? And that’s a huge piece of it.

Steve, if I can, I’d like to turn to a little bit more about UrbanCode and, you know, UrbanCode’s kind of a unique animal, if you will, in that, you know, it was one of the earliest, earliest kinda startups playing in the CICD space, right? And so it had that whole startup culture, if you will, the startup thing going on. And then, of course, you know, acquired by IBM and really become a linchpin of, you know, IBM’s DevOps, and not only DevOps, but you know, in IBM, as you know, DevOps is tied into cloud and hybrid and Bluemix and SoftLayer and all the things you mentioned. You know, it’s such a critical piece of that puzzle.

What is happening lately with UrbanCode? I saw Gartner give you guys some accolades recently.

Boone: Gartner gave us some accolades. We scored very well, as well, on the Forrester Wave that just came out.

Shimel: The Forrester—yes.

Boone: We were named as a leader in the—yep, in the Forrester Wave. So, that was exciting. It was a great score for us. We’re about as far right in that quadrant as you can be.

And there’s a lot of really good things coming out. I think the reason we scored so well is that they’re looking at the strategy within UrbanCode and seeing that, you know—as you mentioned, this isn’t our first trip around the block. We’ve been helping customers do this for over 10 years. And for us, you know, we work with companies that are small startups to everything that are enterprise financial institutions and healthcare and government agencies.

So, there are, at any given time, different, I’ll say, business focuses that are in a different spot of transition. So, I can go to an enterprise and talk to 30 different groups and organizations in that enterprise—they’re all in a different maturity, they’re all in a different level and area of that DevOps transformation. But what we’re able to do is, we have a solution that can help everybody regardless of where they’re at, and as they mature together over time, ultimately help them reach the goal where the company wants them to be.

You know, some of the new things that we’re focusing on—you know, last year, part of our vision, we had announced at Interconnect our DevOps Insights product as well as our continuous release product that are focused on helping customers one, transition into DevOps, do a lot of that deeper reporting and ROI analysis on where they are in their transformation, but as well as help companies manage to the cloud and for the cloud.

What I mean by that is, you know, today, we talk about cloud like it’s ours, but for large enterprises, it’s still very much a challenge. You know, it’s hard for a team to just go request access and say, “Hey, I’m gonna push my data to the private cloud.” There’s still a lot of—or even public cloud, whatever it might be. There’s still a lot of hurdles to that.

So, what we’re trying to do is, as teams embrace this and they’ve got deployments going on-prem and off-prem, how do we organize that? How do we have visibility and traceability and understand as you’re taking large applications and breaking them down, let’s say, into microservices? You know, some of those applications are easy to re-architect, some are not. And sometimes you’re left with applications where you’ve only got maybe three quarters of that application re-architected, or you’ve got databases that are always gonna be on-prem, or you’re using mainframe services.

And that’s really where the UrbanCode products excel, is allowing you to really deploy anything, anywhere, but also have a cohesive look at, what are the interrelated appendices of those parts? If something on my backend mainframe changes, how is that affecting the things that I’ve deployed into my mobile app? And if something needs to fall out of just release, you know, what’s the impact, even? How is that gonna affect business? And I think those are some of the main reasons why we scored well within the Forrester Wave and why they marked our strategy so high.

Shimel: Absolutely. You know, Steve, we’re coming up on the end of our allotted time, unfortunately, but I wanted to mention one thing if we can talk about it, and that is that you spoke about Interconnect, which has been the big IBM DevOps related show, as well as other technologies for the last couple years. This year, IBM is kinda consolidating a lot of the shows they do into a pretty big mega-event called Think 2018, and of course, that is gonna be once again at the Mandalay Bay in Vegas, and it’s happening March 19th to the 22nd. I believe the call for speakers has just opened, and I’ll put some links in the show notes so that people can, if they wanna speak or if they want to attend the event would be great.

But in any event, what’s UrbanCode’s plans around Think 2018?

Boone: Yeah, thanks. I hope folks do and are able to register and come out. It’s going to be a fantastic show, and it is very much a mega show for us. So, we’ve taken—I believe there’s 11 different topics that really, I’ll call them focal points or even think of them as investments within IBM. Everything from cloud to Watson to mobile to security, internet of things—there’s a number of different topics going on at this.

UrbanCode will be under the cloud focus, and we’ll—underneath the cloud topic, there’s a section specifically for DevOps. So, if that’s what you’re interested in, come out and check us out—we’ll be there. We’ll be talking about our latest release that we’ll have done at that time, and we’ve got a lot of really cool features that were actually in development and testing right now that we plan to announce at the Think conference, so without be demo-ing those, and we’ll have—as always, have a bunch of UrbanCode customers there sharing their ideas, sharing their experiences, and really helping educate how they’ve transformed their business.

And I think what a lot of folks will find appealing is that it’s never a one tool solution, right? And that’s one thing I always encourage folks is, when you’re trying to be in a DevOps transformation, a single product, a single methodology—it’s not gonna do it. You really need to embrace the various tools that are in the market, you need to embrace existing tools that are already in your company, and these are gonna be working examples and explanations of how some of the top companies in the world are doing just that using UrbanCode and using a variety of tools that we support.

Shimel: Absolutely, absolutely. Alright, Steve, we’re actually way over time, I apologize, but I think we got some good information here that people will be interested in. I want to thank you for being our guest this week on DevOps Chat and invite you back soon. We want to hear more about Think 2018 as we get closer as well, but good luck with UrbanCode, Steve, and we’ll speak to you soon.

Boone: Hey, Alan, thank you. As always, appreciate you having me today.

Shimel: Alright. Steve Boone, Product Manager, UrbanCode Deploy—or Product Owner, excuse me, UrbanCode Deploy. Thanks for being our guest on this DevOps Chat. This is Alan Shimel, and we hope to see you soon on another DevOps Chat.

— Alan Shimel

October 9, 2017
DevOps Chat: IBM z14, Built for DevOps from the Ground Up, with Hayden Lindsey

IBM recently GA’ed perhaps its biggest zSystems mainframe release in the last decade or longer. The z14 mainframe from IBM has also been designed from the ground up to be DevOps-empowered. From APIs and other integrations to language support, the z14 is IBM’s most advanced mainframe ever. I had a chance to speak with Hayden Lindsey, VP of DevOps Enterprise Systems for IBM, about the z14.

Hayden gives us the low-down on how the z14 has been designed to work in hybrid environments. It also works well with modern CI/CD tools such as Urban Code and others. Additionally, APIs give it the ability to integrate with many different environments, tools and apps. It is truly a mainframe for today and beyond. Hayden does a great job of describing all of this.

As usual, the streaming audio of our conversation is below, followed by the transcript of our conversation. Enjoy!

Audio

Transcript

[su_pullquote align=”right”] [su_custom_gallery source=”media: 117632″ width=”130″ height=”130″] Hayden Lindsey

Hayden Lindsey, Vice President & Distinguished Engineer – DevOps for Enterprise Systems. Hayden is responsible for the development, product management, sales enablement, and services of this portfolio. He has worked at IBM for 28 years and has held a variety of positions, including software developer, product architect, product manager, co-leader of the Eclipse tools platform, and director of the WebSphere Studio/Rational modeling and construction tools. He has a bachelor’s degree in Mathematical Sciences from the University of North Carolina at Chapel Hill.[/su_pullquote]

Alan Shimel: Hi, everyone, this is Alan Shimel, devopsy.kinsta.cloud, here for another DevOps Chat. Our guest on this episode of the chat is a good friend of ours, Hayden Lindsey, VP, Enterprise DevOps at IBM. Hi, Hayden, welcome to DevOps Chat.

Hayden Lindsey: Hi, Alan. Good to be with you again.

Shimel: Good to have you here. Hayden, it’s a big day—big day for the folks over at the IBM Enterprise team. It’s the general availability of z14 today, isn’t it?

Lindsey: It sure is. Yes, we announced this back in the middle of July and we’ve now been making our products available. A lot of mine were available the latter part of last week, and now the box itself, GA, today. So—a big day.

Shimel: Fantastic. And Hayden, just—you know, our audience being so focused on DevOps, they may not realize the full scale of what the z14 release is about. What it is, it’s a combination of hardware—as you mentioned, a new box. There’s a ton of software, there’s a tone of integration—it’s just chockfull of all kinds of goodies. Can you give us kind of a—at a high level, the scope of z14?

Lindsey: Sure. And I think what you see is the result of pulling software, both middleware and tools, from the various divisions that we used to have like Rational and WebSphere and moving those into a single z or mainframe focused brand.

And so, in contrast to most prior hardware releases where you’d be hearing about the speeds and feeds and, you know, the z13 had the fastest processor of any box on the planet—this time, the focus is more on the entire solution that involves both hardware as well as software and tools. And so I think—we worked on that, we did design thinking, we had sponsor users, we did the whole nine yards form the hardware up through the operating system, middleware, and tools, and I think that made a big difference.

And so this time, for example, we have something called pervasive encryption. We all know how important security is, we all hear about these breaches that are happening—Experion being the most, or Equifax being the latest one. And, of all of the records that have been stolen, and I think it’s something like 9,000,000,000 since 2013—only 4 percent are encrypted. And this new mainframe lets you encrypt 100 percent of the data with no impact to performance. So, that’s just—that’s one example. Clearly, there’s hardware stuff there, but there’s also middleware that had to be involved in making this solution. So, that’s an example—it’s really cool.

Shimel: That’s actually a big example, Hayden, because you know what? Encryption has been around—I mean, I spent 20 years in the security space and encryption has been around for most of that. The problem was the hit you took on performance when you encrypted and then had to decrypt and re-encrypt just the latency and—

Lindsey: And the programmer had to do it. [Laughter] Or the database administrator had to set it up for the database, but then what about when it was being used in the application? And so that was—this is what is being solved, where you don’t have the time inhibitor of people doing it, and then you also don’t have the performance impact where it makes a system unusable.

So, I think this could be really groundbreaking for the companies and the government agencies around the world that deal with sensitive data.

Shimel: Sure—and we all do now. Hayden, you said something else, though, that I wanted to key in on, and that is sort of moving away from the speeds and feeds, if you will, metrics of—you know, to measure the value of anything. And I worked with a woman once, and she used to call that bag diving. Right? You know, when you gotta start getting into the speeds and feeds to show the value of your product, you’re diving into your bag instead of talking the true value.

Lindsey: Right.

Shimel: So, I’m happy to see that that’s kind of the path that IBM is taking, talking about the value, but I also think it’s a result, as you said, of so much being added into here, right, from the design thinking around the entire release, if you will, to the integration with things like cloud, with the DevOps entire tool set and methodologies that IBM and others have developed.

This is so much more than just, “Oh, we put—this is the next iPhone with the faster processor.” This isn’t the next z with the faster processor, it’s much more than that. As I think I—maybe you said it earlier or maybe we talked about it off-mic. This is probably the most substantive release for z in at least a decade.

Lindsey: I think it is, and of course, the market will tell us if our aspirations come to bear or not, but I certainly think the encryption element is just—well, I think it’s phenomenal, and it could be very, very, very significant for virtually any company out there.

And then we’ve got more on machine learning and analytics so that you can do in transaction analytics rather than doing it after the fact and having to try to back out or just write off fraudulent transactions. And, of course, we’ve done a lot with our DevOps portfolio compilers. But I really do think, maybe, since we put Linux on the platform, it’s that significant.

Shimel: Wow. Huge. So, Hayden, we are about DevOps here, so let’s focus in a little bit. I mean, one of the nice things is, I’ve seen some briefings around how you can use the new z14s with the IBM Enterprise DevOps solution and really sort of leverage—I don’t wanna use the term bimodal multi-speed nonsense. Leverage integrating your z system with cloud systems into one coherent business strategy. How’s that sound? [Laughter] So, talk about it.

Lindsey: Yeah, so one of the three themes for the release is open and connected, and that obviously ties into a hybrid cloud strategy. It ties into, you know, a digital economy or digital transformation. It ties into API economy—whichever angle you want to take, you have to be able to make the data that resides on the mainframe, which is estimated that roughly 80 percent of the Enterprise data in the world resides on and is managed by the mainframe, and about 70 percent of the business transactions.

And so, if you want to, though, make that available to your new iPhone X app, as we saw introduced yesterday—you know, or 10 or whatever they’re gonna call it.

Shimel: Mm-hmm. Yeah, they’re calling it 10.

Lindsey: They’re calling it 10 using a Roman numeral.

Shimel: Yeah.

Lindsey: But, you know, if you’re gonna do that, you have to make it easy to access the data and transactions, find those transactions, understand them, because very likely, they were written by somebody who’s not around any more or had moved on to other jobs. And so, you need to have tools that make API enabling and opening up and connecting to the mainframe easy and efficient, and just as easy, just as efficient as you would if you were opening up something on the Linux platform—although, of course, you have Linux on z—or a Windows box or anything else. So, that’s—it’s essential that we allow z to participate in the broader digital economy, API economy, and that’s what my team has been focusing on, along with other teams in IBM.

Shimel: Sure. So, now, Hayden, in that same vein, you know, there’s still that mainframe attitude where, you know, we don’t open our mainframe up to all of these APIs, and maybe we don’t want to hook into our systems of engagement, you know, up in the cloud or what have you.

For clients listening out there—and a lot of our listeners are Enterprise class, they work in Enterprise class organizations—how important is it that they really consider opening up, you know, their mainframes to this API economy, as you called it?

Lindsey: Well, I think increasingly, certainly, the IT and line of business executives, the clients with whom I work, are realizing they have tremendous assets that they could leverage if they were to make them available. Nobody—at least no companies I know of, or government agencies, have the resources to just recreate everything from scratch. And, I think if you look back at what the analysts were saying back in the SOA era, they said, you know, it was five times faster to create a service leveraging something that exists that already does the same thing or something very similar than it is to create it from scratch—not to mention the fact that, if it already works, you’re likely to have higher quality as well. And I think the exact same analysis would prove to be true now that we’re talking more about RESTful APIs.

So, I think more and more clients realize they need to expose that value. The key is, just, it’s sometimes daunting when you’ve got—you know, the estimate is like 250,000,000,000 lines of COBOL, not to mention PL/I and Assembler and 4GLs and so forth. It’s getting your arms around applications that were probably created in a more monolithic, less well-structured fashion. You need to do refactoring. You need to discover what is there, and then put together a plan for doing that API enablement.

But I think people know they need to do it, it’s just, sometimes it’s viewed as a daunting task and they have to figure out how to get started, and we have something called the digital transformation model that we’re rolling out to help our clients put a plan in place.

Shimel: Got it, and I agree. So, you’re just setting me up for my next things here, but—so, that’s the biggest question we hear at devopsy.kinsta.cloud, Hayden, which is—hey, this is all great. How do we get going? How do we roll this? How do I get executive buy-in? How do we—is there a one, two, three? Is there a blueprint I can follow.

So, z14, let me throw it right back to you—where do we start? How do they get moving with this? How do they—and specifically, how do they start incorporating the DevOps and API stuff into this?

Lindsey: Yeah, it’s the question that I hear from virtually every customer I talk to, and I’m getting ready to do a tour in Europe next week, and I’m sure it will come up in every single meeting. And the fact is, every customer is different, so there’s no single answer. And, within any given client, they have applications that span the gamut from nearing end of life to ones that are under active or brand new development. And so, what we’ve—but, of course, there are patterns and similarities across clients and application types, and there are best practices that we have gleaned by working with clients through the years, and that’s where I mentioned this thing called the digital transformation model.

We’ve shifted to this way of working with our clients to focus on applications rather than one answer for the Enterprise—hey, you should start with deployment automation, or you should start with test automation. That answer should not be an Enterprise answer, it should be for this suite of applications because of what their current state is, the as-is state, and what you desire the to-be state to be. If you just need something to run efficiently and you’re gonna replace it in a few years or retire it, all you want it to do is run efficiently.

So, use our latest compilers, but you know, the fact of the matter is, putting in a fully automated pipeline is likely a wasteful effort. Whereas, on the other end of the spectrum, for the things under very active development, that’s where you want to do DevOps in its fullest, and really, it’s just a matter of what steps do you take to get there.

And so, this model that we’ve come up with has four levels—the first one I described about, just do your compiling, is run—just run it. Just run it efficiently. The next is maintain, the next is expose, the next is evolve. So—I mean, and I don’t know if we’ve got the best names in the world, but the fact is, you really need to think about, for the business, what degree of DevOps adoption do you need for a given application or application suite. So, that’s the more, I think, realistic answer that we’ve been using with clients this year and a tool that we’re using that’s different from what we’ve done in prior years.

Shimel: Excellent. So, Hayden, I mean, just to illustrate this, I remember back at Interconnect last year, you know, we had the whole little DevOps TV booth set up, and I was interviewing some IBM clients. And one of them, it was a bank, and I forget if they were from Poland or the Netherlands now, or maybe even Australia. They were IBM’s z System customer and they had just updated, I wanna say, from COBOL 4 to 5—maybe it was 5 to 6, I don’t remember now.

But they had just updated their version of COBOL, and it made a huge, huge difference for them in terms of performance and—

Lindsey: Yeah. Yeah, exactly. You know, we’ve—one of the things that our compiler team does every single release, and this starts from the very earliest days of, we were just imagining what the new mainframe or new power platform is going to be. We were working hand in hand with the hardware folks.

And, you know, with COBOL specifically, where something like 70 percent of the world’s business transactions are running COBOL, obviously, performance does matter, and so this is where you can get into a little bit of feeds and speeds. Mainly because, not because—some of the numbers aren’t eye popping, but it’s because you can be more responsive for your clients. But with some compute intensive apps, they run 16 times—not percent, times—faster on the latest compiler, which is 6.2, versus 4.2, which may be where that client was coming from. So, that’s skipping the version 5 things, but we still have the majority of our clients on the 4.2 version.

So, it’s tremendously faster, but this is by doing this joint development. You know, if you put new instructions or new vector support in the hardware and the compiler doesn’t generate these new instructions, well, then, obviously, no client is gonna be able to take advantage of it unless they want to write their own assembler. So, you know, our compilers are delivering tremendous value, and I gave you a COBOL example, but you get similar results with PL/I and with our automatic binary optimizer that basically just does the, tries to do the work that the compilers do, but just working on binaries rather than having you go back to the source.

So, it’s a big deal. You know, and the less—it’s maybe a bit more mundane. Yeah, the stuff runs faster and, as you said, diving into the bag. [Laughter] But, you know, when you’ve got numbers like 16X or 5X or what have you, that’s huge.

Shimel: It sure is, it sure is. So, Hayden, you know, I mentioned Interconnect, too, and as we’re running low here on time, I just wanted to quickly prompt you on that and let our listeners now.

So, this year, Interconnect is part of an even bigger kind of unified conference that IBM has put together called Think—Think 2018, I believe it’s called, and if I’m not mistaken, it’s March.

Lindsey: Yes.

Shimel: Go ahead.

Lindsey: Well, you might see a trend here. [Laughter] Because, you know, Interconnect was the combination of Impact and Innovate. Innovate—I think that’s the name it was. I’ve kinda forgotten, but anyway, we had a Rational conference, we had a WebSphere conference, we had IoT stuff and all that. And now we combine those into Interconnect—at least the WebSphere and Rational stuff. And it got bigger, and now we’re doing something that is more or less IBM-wide and it’s called Think. It’s gonna be the week of March the 19th at the Mandalay Bay in Vegas, so still in Vegas like most of our other conferences have been of late.

And so, I think there’s pros and cons to having a more broad, where we can tell the full IBM story, and that’s the focus, and you’ve got SMEs from all the different areas of the country, be it cloud, cognitive, Zpower, what have you. But I think that’s great, but because you do have those experts, and we will have the breakout sessions or keynote sessions on specific areas, be it DevOps or z or compilers or deployment automation like UrbanCode.

So, there will be still those specialty sessions, and yet you get the big picture. And the one thing that I would like to ask your listeners is, the call for papers is open, and you know, we are shooting for having 100 percent of the talks in the various tracks either be a customer or partner only, or being customer and/or partner jointly with an IBM-er, but we’re just really trying to get away from IBM-er talking head telling a story without a partner or a customer there saying what they’ve done in real life with a given solution in a given area.

So, we’d really love to have as many partner and client nominations as possible.

Shimel: I love that idea. You know, I shared a panel the last two years, Hayden, on Dev—I think they were on, well, it was on DevOps and then SecOps. But, you know, I tried really hard to balance it with—yeah, we had one person from IBM, but we also had an analyst and then we’d have a partner and then a practitioner. And I think that sort of balance gives it, it makes it—

Lindsey: It adds some legitimacy to the whole thing and different perspectives.

Shimel: Yep. Just real quick, for anyone listening, if you go to IBM.com/events/Think, you can get all the scoop there and follow the links to submit. And as Hayden said, if you’ve got something to say and share with people, it—having been to three or four of these, or more, it’s a great platform. So, I’d encourage everyone who would like to participate to do so. And even if you don’t want to speak, but if you want to go really understand what’s happening, whether it be with Watson or z Systems or hybrid cloud or Bluemix or any of those things. You know, if any of those are important to you, I think it’s a great show to attend.

Hayden, we’re about out of time—we’re actually over time, but that’s okay. Thanks so much for taking the time on what is a busy day with the general GA of z14. Best of luck with it. Let’s check in, I don’t know, maybe before the end of the year, and see how—you know, what kind of market reception a lot of these features and capabilities are receiving and we’ll see where the rubber is meeting the road.

Lindsey: Sounds good, Alan, and thanks, again, for your time.

Shimel: Thank you for your time. Hayden Lindsey, VP, Enterprise DevOps with IBM on GA Day for z Systems z14. Thanks, Hayden, have a great.

Lindsey: Okay. Bye for now.

Shimel: This is Alan—thank you. This is Alan Shimel for devopsy.kinsta.cloud. We’ll see you soon on another DevOps Chat.

— Alan Shimel

September 27, 2017
DevOps Chat: The Continuous Delivery Map w/ Scott Wilson, Automic

Wouldn’t it be nice to have the entire continuous delivery topography laid out in a nice map that shows how they are all interconnected? Sort of like a subway or metro map? Well now you have it and it is interactive! The good folks at Automic, a CA Technologies company just released their Continuous Delivery Map. It is really cool and they are adding to it all the time.

I caught up with Scott Wilson of Automic and had a chat about the Continuous Delivery Map. As usual the streaming audio of our conversation is immediately below, followed by a transcript of our chat.

Audio

Transcript

Alan Shimel:                Hey, everyone, Alan Shimel, devopsy.kinsta.cloud here for another DevOps Chat. Welcome and welcome to our guest, Scott Wilson, Automic, a CA Technologies company. Scott, welcome back to DevOps Chat

Scott Wilson:               Thank you, Alan. I’m glad to be here.

Alan Shimel:                Glad you’re here with me. So, Scott, you know, lot going on with Automic, obviously – always is – but I wanted to focus in today on some pretty cool interactive graphic – well, it’s more than just a graphic. It’s really a whole project that you guys have launched and it’s called the “continuous delivery map.” For those following along at home, if you wanted to check it out, you can get to it at automic.com/continuous-delivery-tools and – dash or a hyphen. Scott, you know, assuming people are listening to us but not able to get to the site this second, can you describe for us what the continuous delivery map is?

Scott Wilson:               Yeah, so the continuous delivery map is really just a way to visualize a topography, if you will, of all the different tools that are in the continuous delivery value chain, and there are lots of tools. And we found, in talking with a lot of prospects and just other companies in the industry, that amongst IT professionals there’s a bit of confusion on what kind of the best use case is for many of the tools, mostly, Alan, due to so many of these tools having a great deal of crossover functionality, right? It’s kind of muddied, blurred the lines a bit.

And so, in thinking about a good way to help people out and kind of visualize the tool chain used to get an application into production environments, we took inspiration from metro rail systems, like the London tube or the New York subway, and so we built out a map that looks similar to that.

Alan Shimel:                Yeah. I mean, for those of you, as I say, who maybe can’t get to a computer right this second, as you’re listening to this, it really is. It’s based on a subway map or a tube or it could be the Washington metro or the Boston or Tokyo or anyplace else, in that you have a central hub and then there’re different lines that are color-coded. And each of these color-coded lines represent a lineage or a line of a particular functionality in the continuous delivery world. So, for instance, there’s a line for cloud, IaaS and PaaS. Another line for middleware, another one for CI tools. Another one for artifact repositories. And, along that line, the stops are all of the different companies that kind of play within that are or are on that, and it’s not just companies – it’s actually the products of these companies that play on that particular branch, if you will.

So it’s actually pretty cool, Scott, and what I like about it too is, though, look, plainly and clearly, Automic is a vendor. I mean, there’s no favorites here. You’ve done a pretty exhaustive mapping or the whole topography of the continuous delivery world, it looks like, to me anyway.

Scott Wilson:               Absolutely. We really wanted this to be agnostic for the tools. We’re really just trying to help the community understand, you know, the landscape for continuous delivery, and, as you mentioned, the central hub is really the way you would bind all those many plethora of tools into a coherent pipeline, right, to safely and reliably deliver apps to production environments. And, yeah, this definitely respects that. Ultimately, we’re gonna be opening this up to the community so that people can comment or keep this updated ’cause there’re always new tools coming on board and other tools or open-source projects that kind of fall out of vogue, so we’re looking to really make this more interactive and far – we’ll keep it up to date.

Alan Shimel:                Yep. And, you know, again, trying to visualize or paint a picture for people who don’t have it in front of them, at every stop on every branch, if you will, it’s a link, and if you click on that link, it gives you a little pop-up with a little information about that particular company or product but also links through to their full websites or what have you. So it really is – I could see this being a really useful tool for anyone interested in the CD kind of world. There have been – I mean, clearly, Scott, right? Full disclosure: there’ve been other companies that have tried to organize, if we will, the CD world, but, really, using this paradigm of the subway map and the branches and lines, if you will – maybe it’s just ’cause I’m from New York and I’m used to subway maps –

[Laughter]

– makes a lot of sense to me.

Scott Wilson:               Right. Well, we’ve heard that feedback as well that that’s just – well, you know, continuous delivery’s about movement, right? You’re moving things along and it just seems to help visualize it. You know, a lot of the data from what other folks have done is similar, right – a big list of tools – but just being able to put it in a format like this, we’re finding a lot of people go, “Ah, this makes sense. I would use these set of tools. Source code management fits here and deployment automation fits there.”

And it’s helpful because I think, without presenting it this way, you’re just left to a hodgepodge of tools and you’re like, “Yep, I got ten of these and two of those and I’m good.” When you look at it in this format, you realize, “Oh, well, I could actually go further. I could do more or I could better organize things,” or maybe even take some of the burden off a tool that you keep having it be more than it was designed for and actually use a best-of in another category, or, as we represent it as, a color-coded rail line.

Alan Shimel:                Yeah. Yeah. And, of course, you know, the thing about projects like this, Scott, is they’re, in some ways, a never-ending story. They’re constantly morphing, changing, growing. And, I mean, the good news is you’ve got a great start right here; the bad news is you guys need now to keep this up, week in, week out, month after month. What are the plans, going forward, to keep it current and fresh?

Scott Wilson:               Excellent observation and point. We are looking to ultimately open this up to the community, so this page will not only be as it is now; it’ll be far more interactive, where visitors can come in and recommend tools that aren’t on here, maybe further defining particular lines or branches that we have, upvoting, downvoting various tools, and, yeah, so we’re looking to have that community help us keep it up to date. In just doing the research for this and playing with many of these tools and looking at their viability to be on the map, as you said, it was a ton of work. And so it’d be impossible, with the growing market, to do that on our own, and we’re definitely looking forward to collaborate with the DevOps community at large in keeping this current, the information current and fresh and, of course, far more interactive and useful, as we go forward.

Alan Shimel:                Yeah. I mean, you know what? I mean, this is great and I don’t know how you would visualize it, but it would be great to show sort of connected dots, in terms of how companies or products actually integrate or work together. But that –

Scott Wilson:               So, yeah, not to give away – [chuckles] – so much what we’re planning, but, yes, you’re absolutely correct. That is something that is on our roadmap, what we’re planning. Indeed, what we think would be useful for this is to allow us to kind of rank or order the tools and use a kind of a most popular or what the market, the community says, “Now this is the best practice set of tools.” A simple example would be SQL Server and Oracle. Right? If you’re going down the RDBMS line, the database line, then, well, those two are kind of the giants. And so by ordering them such a way, you would be able to come in, list the tools that you have, and be able to visually see, “Are you kind of following what everyone, what the consensus best practice is? Or are you have a lot of outliers?” And I suspect a few outliers here and there are okay, but, you know, if you’re going two four outlines, you might be putting yourself at risk.

And sometimes I think it’s just to help you answer that big question, is “I don’t know. Should we go with this tool or this tool?” Well, you could come here and, in future releases, be able to see what the community is saying the best of or the next best of, right, and have it ordered and you’d be able to see that in a nice map, visual way, to understand and help you to, hopefully, make decisions on what tooling you should consider or not.

Alan Shimel:                You can also see if you’re taking the express or going on the locals. There’s a lot that a clever marketing person and someone with a good knowledge of the market here in the CD space can really make some hay with this, Scott. And, you know, beyond cute, it’s actually pretty – a really useful tool here.

Scott Wilson:               Yeah. Appreciate that. Like I said, we’re looking to make it far more useful and what you hinted to and what I’ve just discussed is really make it really interactive and help you measure yourself against what the market or the community is doing, what the norms are, best practices and so forth.

Alan Shimel:                So I’ll include a link to this, Scott, in our show notes when we publish, but, for those who may be listening on iTunes or SoundCloud or audio only, again, the URL for this CD map is automic.com/continuous – dash or hyphen – delivery – dash or hyphen – tools. And you could check it out there. Scott, you know, in real DevOps fashion, upgrades here will be continuous, right? There’s not a Linux version planned or anything like that, I would assume

Scott Wilson:               Correct. Yes. So we have continuous sprints planned. New vendors are actually in our current sprint, that are coming out, and, yeah, so you’re absolutely right. If we’re gonna do something on continuous delivery, then we ourselves are looking to be agile and looking to keep it fresh and then, ultimately, have one of the inputs to those sprints be the community, community feedback and input.

Alan Shimel:                Got it. So, Scott, this is really great. Congratulations to the whole team at Automic who worked on it. It’s a piece of work here that I think is highly useful. What else is new at Automic, Scott? Anything noteworthy you wanna report on

Scott Wilson:               Well, what we’re shipping here lately, in the next few weeks, is a incremental release of our application release automation product, version 12.1. There are several enhancements that are coming out, going GA here, in the coming weeks. We’re pretty excited about that and some of the additional enhancements. There’ll be a lot of information coming out in a few weeks about all of that and the functionality and things that we’re doing with that. And then, you know, just additionally, the growth and recognition within the CA company, as an automation business unit, and, yeah, we’re keeping pretty busy with automating not just things within the continuous delivery value stream or DevOps tool chain, but also within the CA ecosystem itself. There’s a lot of growth. And so, really, what’s happening with Automic is we’re really able to help show how we can automate, really, the modern software factory.

Alan Shimel:                Yep.

Scott Wilson:               That’s kind of one of the – falls in line with what CA is trying to do, one of the core tenets. They’re trying to reach out to the community and the marketplace.

Alan Shimel:                Absolutely. All about software development life cycle and software supply chains.

Scott Wilson:               Yeah.

Alan Shimel:                Well, Scott, thanks for giving us a peek behind the scenes at the continuous delivery map. We’ll try to feature this on devopsy.kinsta.cloud and we’ll be watching as it continues to develop, adding even more features or functionality, but it’s pretty cool stuff.

Scott Wilson:               Well, thank you very much and, as always, I love being here and grateful you had me.

Alan Shimel:                Well, we’ll have you back on again then. You know, Scott, flattery will get you everywhere.

Scott Wilson:               [Laughs]

Alan Shimel:                Thanks

Scott Wilson:               That’s so true, isn’t it?

Alan Shimel:                Yep. We’ll have you on again. Scott Wilson, Automic, a CA Technology company, talking about their new continuous delivery map here on DevOps Chat. Scott, thanks for coming. Hey, everyone, thanks for listening. Hope to see you soon on another DevOps Chat. Until then, I’m Alan Shimel for devopsy.kinsta.cloud and we’re out of here. Thank you.

— Alan Shimel

September 7, 2017
DevOps Chat: Chef Update with Ken Cheney, Chef CMO

There are always new developments going on at Chef. We caught up with Chef CMO Ken Cheney to give us an update. Last time we spoke with Ken was right after ChefConf. Since then, Chef continues to move forward on several fronts including Habitat, Automate and INSPEC. We speak to Ken every other month or so, as it is always good to know “what’s cookin’” at Chef.

As usual, the streaming audio of our conversation is immediately below, followed by the transcript of our chat. Enjoy!

Audio

Transcript

Alan Shimel: Hey everyone, Alan Shimel, editor in chief of devopsy.kinsta.cloud here, for another DevOps Chat. Today’s guest on DevOps Chat is our friend Ken Cheney, CMO of Chef. Ken, welcome back to DevOps Chat.

Ken Cheney: Alan, it’s great to be here. Thanks for having me.

Shimel: Thank you. Ken, I apologize, between your schedule and my schedule, it’s been a while since we’ve had a chance to catch up. I think the last time we left off it was – was it right after Chef Conference, ChefConf?

Cheney: It was actually right before ChefConf. So it’s been a couple months, right? Given that was at the end of May.

Shimel: Ken, I don’t think I’ve been home for more than two or three days at a time since then. So yeah, it has been. But for our listeners who maybe aren’t lucky enough to be down in Austin and ChefConf this year, can you fill us in a little bit about maybe what we missed?

Cheney: Yeah, so ChefConf this year, as you mentioned, was in Austin, Texas. And you know, I think the highlights of ChefConf, on the product side, were some announcements we made around Chef Automate and bringing in our open-source tooling fully under that umbrella of Chef Automate. So Chef Automate is our commercial offering. And first and foremost, we brought in InSpec fully, so now, from one spot within Chef Automate you can see both how you’re doing in terms of your infrastructure and how your infrastructure automation is going with Chef, but also from a compliance perspective you can see what’s happening in terms of policy through the Chef Automate UI. So it’s really – the product has evolved from how it was working before, where we essentially had two servers for and now you have a single, common UI for looking across all the various data points

In addition we brought in the Habitat data so now you can see the state of your Habitat instances that are running in the wild. And you know, what I find really interesting about what’s happening with the compliance front is that, you know, we’re really evolving quickly from just being focused on sort of core compute elements to now expanding InSpec out to cover up on cloud-based APIs. So we can now go at AWS and Azure and be able to scan those, as well as VMware environments. So you know, we’re expanding InSpec to be a language that’s not just appropriate for compute, but also for broadly managing all of your infrastructure as code. And so that was announced as well at Chef Conf. And I think that’s a bi move forward. You’re going to see that continued expansion of that InSpec language and capabilities to go after a broad set of other types of infrastructure in the near future.

And it’s an area where we see just a tremendous interest and uptake from our customers and users. So anyone who hasn’t tried out InSpec, I really encourage them to try it as part of Chef Automate if you want to actually see that InSpec data roll up into common policy views and really understand how you’re doing at an infrastructure level, both in terms of the state of your infrastructure but also how your infrastructure is conforming to policy around compliance and security. You get that from one place. And in this world of WannaCry and other exploits that are happening, it’s amazed me how many organizations, when tools like InSpec exist, still have giant vulnerabilities, right? And here we have this open-source tool that can solve this problem of really understanding what is your exposure. And then you can use a tool like Chef to actually remediate and fix it. It just blows my mind that it’s still a common occurrence.

Shimel: It blows your mind, Ken? For 20 years it’s blown my mind. For those of us in the security space, it’s no secret that well over three-quarters—actually, probably over 80 percent or 85 percent of attacks and successful attacks actually take place not because of what we used to call Zero Day or unknown vulnerabilities, but because known vulnerabilities were not patched.

Cheney: That’s exactly right. That’s exactly right, yes.

Shimel: And that’s the key. I mean even today –

Cheney: Yeah, and –

Shimel: It’s crazy. I’m sorry, go ahead, Ken.

Cheney: Oh I was just going to say, one of the common things, you know, as many organizations haven’t really fully automated – and so they reintroduce the vulnerabilities into the wild all of the time. And what I love about what you can do with InSpec is you can actually – because you’re managing as code, every time you test your software, every time you push a configuration with Chef, you can verify that you’re not reintroducing to file that or something on a keyboard the reintroduces that potential hole in your organization.

Shimel: Yep, you know – I’m sorry, can you hear?

Cheney: Yeah, yeah, go ahead.

Shimel: I’m getting a little audio back. I hope this is recording well. Ken, we did a survey a while back where only 75 percent of organizations are actually scanning their code for vulnerabilities prior to deployment. And you know, what are the other 25 percent thinking?, is kind of what I think. But anyway, on the topic of security, Ken, I wanted to quick mention that Matt Ray of Chef is actually speaking at a conference I’m doing as a part of RSAAPG on DevSecOps next week. And Matt, I think, is based in Australia, correct?

Cheney: Yes, he is. Yeah, Matt is based in Australia and he will be talking about InSpec, and folks who are there can attend his session and learn more, for sure.

Shimel: So maybe it’s because I’m traveling to Singapore and so it’s kind of right in my face, but to me, it’s this global – I mean, DevOps has really become a global – I don’t want to use the word “phenomenon” – but a global force. And we’re seeing it

Cheney: Yes, it is.

Shimel: – you know, certainly in EMEA, but we’re seeing it in AP. And then just this week, Ken, I think Chef just announced their first Latin American partner, right?

Cheney: Correct, correct. Yeah, we are definitely seeing DevOps at a global level and seeing broad interest. And what’s interesting is that – Alan, I’ve been in the industry a while, and it used to be a little bit of a lag – you know, a several-year lag before you’d see markets such as Latin America or parts of Asia pick up technology that would originate in the United States. Or process ideas. But things move much more quickly now and you’re seeing global companies with operations in India and operations in China. And so we as a company do a lot of activity at a global level. You know, if you look at how we’re doing meet-ups and where we’re doing meet-ups, they’re happening all over the place. And our partner ecosystem, which is well over 300 partners, covers the globe, because we see that demand.

Now how we enter any given market varies depending on what’s going to work best in that market. So some markets we address through partners and some markets we actually put our own physical presence in that market.

Shimel: Yeah, we see the same thing at devopsy.kinsta.cloud, Ken. You know, our readership when we first started was almost three-quarters U.S.-based, and now it’s only about 37 percent, with the rest being global. But it’s more than just spreading through the world. It’s what you said – there’s not as great a lag time. At one point, Latin America was three – we used to tell people, “Oh, it’s three years behind what we’re doing here.” And that’s not the case anymore, certainly.

Cheney: Yeah, I’ll tell you, the highest volume of leads that we get come from the Asia Pacific region.

Shimel: Really.

Cheney: Yeah, so there’s just a tremendous amount of demand coming out of there. I’ll tell you, if we do a meet-up in Bangalore or Delhi, we’ll have 300 people show up to that meet-up.

Shimel: Wow, that’s fantastic. You know, we’ll talk more about that off-mic. But Ken, a lot of what’s driving strong numbers like 300 people at a meet-up and stuff like that is training and availability of training, right?

Cheney: That’s right.

Shimel: And that’s something Chef has always done really well. But you guys recently rolled out – not Pilot, excuse me – what is the name of the –

Cheney: Chef Automate. The Chef Automate Pilot, yeah. We actually rolled out a whole new online learning site called Learn Chef Rally and it’s gotten very fast adoption and has a lot of users hitting it every day. And as part of that we have what’s called the Chef Automate Pilot, which is really targeted at an individual who wants to really understand Chef over the course of maybe a lunch, right? So that kind of lunchtime evaluation where they want to get a feel for how Chef works and what it does for them. But as a whole, Learn Chef Rally constitutes a whole set of modules that will walk you through the various parts of our technology. So if you want to learn about compliance, there’s an InSpec module and a Chef Compliance module. If you want to learn even about DevOps concepts, you can go and learn about them there on the Learn Chef Rally site.

And we’ve had such strong uptake. You know, we’ve seen a lot of customers who would like to bring that learning site in-house and customize that learning environment for their own company. There’s been such a strong interest. So it’s a great resource and I encourage people to go look at it.

Shimel: Sure. Ken, well, the logical question then is, how do they get there?

Cheney: Yeah, so it’s very easy to get there. You can just go to learn.chef.io and you can get started.

Shimel: Excellent. That’s a good one. So that’s Chef Rally and it’s highly recommended. It sounds like there’s a lot and I’m sure you guys are planning to add more into that. So Ken, we are kind of in the dog days of summer here but it’s certainly not slow, it doesn’t seem, anywhere. Any other news, events?

Cheney: Yeah, well we just passed the one-year anniversary of Habitat and I’ll note that, you know, we at ChefConf made some Habitat news. So we announced a Habitat build service and we made improvements to the Habitat scaffolding, which are essentially build packs to make it easier for people to package up their applications, as well as we’re writing a set of enterprise-ready Habitat plans or common languages, common platforms, such as like BigData, Cassandra, Spark and real common kind of web apps. And so Habitat continues to evolve, and just in the past couple of weeks we announced the pre-release of Habitat for Windows. So along with what we had for Linux support, people can now use Habitat to package up their Windows-based applications. And from our view, Habitat is now the premiere packaging solution for containers. It’s the fastest, easiest way to package an application and have it run in a container and be able to manage it across the life cycle.

Shimel: That rocks. I mean, because certainly, Ken, the one thing that we’re seeing here is the – you know, we talk about the Internet time crunching or compressing time. The pickup on containers? I’m old enough, and probably you are too – remember when VMware first came out, right?

Cheney: That’s right.

Shimel: And through virtualization, it went really quick. The move to virtualization went a lot quicker than let’s say the move off of client server or something like that, from peer-to-peer, or peer-to-peer to client server or what have you. But the move to containers – man, I’ve seen several surveys recently that showed container in production numbers upwards of 50 percent of organizations. And I thought frankly this wasn’t true, but it says something. Right?

Cheney: Yeah well, you know what’s interesting though about that move? What’s interesting about that move, Alan, is that the majority of containers that are running out there are being used almost like a VM. You know, 75 percent of containers right now are running a full OS.

Shimel: Yep.

Cheney: And they’re basically just using it as a way to kind of attempt a higher level of abstraction and remove a little bit more of the infrastructure complexity that they were encountering when they were using VMs. So what I think the next wave is going to happen, I think people are going to actually figure out how to actually better package their applications to actually take advantage of what they can do to remove unwanted dependencies and remove a lot of the weight around the application that they’re currently doing today when they just package up the full OS and all of the broad set of unassociated dependencies that they’re packaging right now. So I expect that’s going to be the next wave and we’re there to help them when they go there.

Shimel: Agreed, agreed. Ken, any shows or conferences coming up, other than of course the DevSecOps that I mentioned, where Chef will be presenting or a part of?

Cheney: Yeah, well yeah, we will be at VM World, coming up. We’ll be at Microsoft’s big event that’s coming up. And of course as we look toward November we have our own community summits that happen in the fall timeframe. So those are a great way that we bring our community together. So the first one is going to be in London Oct. 10 and 11. So that’s coming right up as well. So expect to see Chef and our brand showing up at a lot of different places in the coming months.

Shimel: Great. Very cool. Well Ken, we’re about out of time here. 15 minutes goes quick. But hopefully it won’t be a few months before you’re back on –

Cheney: Yeah.

Shimel: – and we can pick up where we left off here.

Cheney: Yeah, Alan, enjoy your travels and thanks so much for the time today.

Shimel: Not a problem. Ken Cheney, CMO of Chef, here on DevOps Chats. This is Alan Shimel for DevOps Chat and devopsy.kinsta.cloud. Thanks for listening, everyone, and we’ll see you on another DevOps Chat soon.

— Alan Shimel

August 21, 2017
DevOps Chat: DevOps and the Road to Cloud with JT Giri, CEO, nClouds

For many of us in the IT industry, migrating to the cloud is old news. Even the concept of how DevOps can help on the road to the cloud is not a novel idea. However, we need to remember that while many organizations have some cloud-based infrastructure, the real migration to the cloud is still ahead of us. By the same token, while DevOps is more popular than ever, the percentage of organizations that have fully adopted DevOps is still small.

My talk with JT Giri, CEO and co-founder of nClouds, dives into this truth and how companies like nClouds are helping organizations big and small to make the move. As usual, the streaming audio of our conversation is below, followed by the transcript of our chat.

Audio

Transcript

Alan Shimel: Hello, everyone. This is Alan Shimel, editor in chief of devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s DevOps Chat guest is JT Giri, CEO of nClouds. JT, welcome to DevOps Chat.

JT Giri: Hey Alan, great to be here. Thank you.

Shimel: Thank you. Thank you for being here. So JT, let’s start off a little bit about – before we get to nClouds, let’s start off – I don’t know if everyone in our audience has heard of JT Giri and your background. So why don’t we go there first, so you can give us a little background.

Giri: Absolutely. I spent the last ten years doing DevOps consulting before it was called DevOps – so helping companies to streamline their operation and managing complex infrastructure and helping them to put processes in place. My end goal was always to make sure the customer could focus on their end goal, like delivering greater value to their clients. So that’s what I’ve been doing the last 10 years.

Shimel: Got it. And then you founded nClouds. When was nClouds founded?

Giri: Yeah, so it was kind of a transition from consulting to founding this company with the mission of helping companies with cloud adoption and helping them to manage modern infrastructures that would integrate continuous delivery, continuous integration, building better culture. So we transitioned from consulting to a company.

Shimel: And you know what? You’ve done it and congratulations. I’ve done it now several times. And it’s scary, right? It can be a little scary when you – you know, it’s a big responsibility, but ultimately that’s what makes an entrepreneur, right?

Giri: Yeah, absolutely. And I think at some point you realize you can add far more value to your clients if you grow it as a team, especially 24/7 support. One of the DevOps principles is to take ownership, right? So we wanted to provide that to our customers and every gig we do, we make sure we are there for them. You know, we provide 24/7 support and make sure we are responsible for their infrastructure. It’s just simply very hard to do it yourself, you know? So that’s why we transitioned into a company and it’s been great. We’ve done over 100 AWS implementations and the transformation for our clients has been amazing. Before where it used to take them three months to deploy code, now they can deploy everyday. So it’s just been an amazing journey.

Shimel: Yeah, it has. And I mean, you know, again, as an entrepreneur and you having done this too, JT, it’s nice to get some recognition beyond – I mean other recognition is putting the money in the bank and growing the business, right? But it’s also nice to get awards, kudos or some industry recognition that things are moving in the right direction or the arrow is pointing up, as they say in football. And JT, recently nClouds received some recognition like that, didn’t they?

Giri: Yes. Yeah, so we’ve been nominated in the 20 most promising DevOps providers of 2017 and as I was saying, it’s really exciting for us, because we’ve been doing great things for our clients and the transformation has been amazing, where now the customer can focus on delivering value to their clients faster. You know, we help them with cloud migration and streamline their operations. So it feels good to be recognized, definitely. [Note from Editor: Just after our interview, nClouds was named to CIOReview’s 20 Most Promising DevOps Solution Providers – 2017.]

Shimel: Got it. And JT, you know, nClouds is working pretty closely with Amazon AWS, isn’t it?

Giri: Yes, we are an Advanced AWS consulting partner. We’re also an AWS Managed Service provider and DevOps competency partner.

Shimel: Got it. And how is that, JT? Because again, for our folks out in the audience, I’m sure many of our listeners are actually working on AWS-hosted infrastructure right now. But you know, from my experience anyway, there’s people who work directly with AWS and they muddle through it. They may get some training and maybe they’re old hat at it. And then there’s a large segment of I think the industry and of the customer base who really, they need the nClouds of the world. They need AWS expertise to help them make it happen. And I’ve got to assume that that forms a good chunk of your customer base right now, yeah?

Giri: Yeah, absolutely. So Alan, you know, you’re in the space and you know how confusing things are right now. You know, there’s people already moving to server-less and there’s Kubernetes, Nomad, and you know, there’s like five or six container schedulers … They want to be like Amazon or Netflix or Google of the world, but it’s very hard to get there. Since we’ve done this so many times, we have experience working with the client and taking one step at a time. Because if you’re starting out it can be intimidating, because you don’t know – you have a good vision and you want to release code fast and you want to make sure you can innovate fast. You want to migrate to AWS, but it’s very, very tough. And Alan, when we speak with customers, some of them are still starting with the config management conversations, right?

Shimel: Mm-hmm.

Giri: And so we have to kind of tone it down for them. For them, the next step is, “Hey, let’s figure out – maybe we need to work on implementing some kind of config management for you before we even think about micro services,” right? So that’s when someone like us can come in and help you to understand, where can we get the biggest bang for the buck? What should be the next step? And really help you pave the way to go to this transformation with a DevOps path.

Shimel: Yep, agreed. So JT, you know, when we start talk about it though – I want to turn back – you actually wrote an article back in May that was up on devopsy.kinsta.cloud about why your company needs an automated infrastructure now. And when you were talking it kind of triggered that for me. For our listeners out there, why do their companies need an automated infrastructure right now?

Giri: So if you subscribe to lean thinking, anything that doesn’t add value to your customer is a waste, right? So you need to define your work rigorously to be used that way. With automated infrastructure you can actually facilitate that. You can scale up and down based on your customer needs. And then you can focus on adding value to your customer and you can also lower the cost, where you just scale based on the client’s needs – and all this can yield better reliability. You know, the customers will be happy. If you’re not leveraging automation and if you’re treating the cloud infrastructure like on-prem, then you’re not really getting any value out of the cloud. So that’s why I wrote that article, just illustrating that you have to focus on automation and the cloud so you can lower the cost, have efficient workflow, and in return deliver better reliability and better customer experiences.

Shimel: Excellent, excellent. So you know, JT, you and I and people like us, we’re living in a DevOps bubble. We think DevOps is great. We think this type of methodology, this way of thinking, this kind of cultural organization is a no-brainer and of course it has to make things better. But there are a lot of people who maybe haven’t drunk the Kool-Aid, or they just don’t see it. And they’re saying, “Okay, that’s cool. That’s this week’s buzzword. What’s next? How do we keep this going?” Where do you see this going, JT? And when I say this, I mean this whole sort of – I call it Agile IT, because I heard someone at Gartner use the term. But DevOps, Agile, this new way of doing things – where do you see it going

Giri: Yeah, so I think we have a long way to go, Alan. As I mentioned earlier, you know, we are in the Valley and we are drinking this DevOps Kool-Aid. And because we have experienced this, right? Like I’ve done a lot of DevOps transformations and I can see before and after and it’s just amazing when you get the results. But there are a lot of companies out there, as I was mentioning earlier – they’re still beginning to think about config management systems, right? And they’re still doing config management in Pearl. And another challenge I face, especially when we’re working with enterprises, people have gotten used to doing things a certain way and all of a sudden there’s like so many better ways to manage your infrastructure.

So Alan, I think we have a long way to go and I think when people feel like, “Oh, this is just a buzz,” what we try to do with companies is take small steps, right? If they’re still working on config management, try to implement that and show them metrics on how things were before the implementation.

Shimel: So JT, what about nClouds? What’s next with nClouds? I know recently you guys have added some talent there and you’ve got this award going on and you’re getting buzz in the industry. Where do you see the company going?

Giri: Yeah, so our mission from day one has been to drive this cloud adoption and help companies with DevOps transformation. So companies like Google or Netflix, the unicorns, they can really attract a lot of DevOps talent. But there are a lot of companies and a lot of enterprises out there and they’re not able to attract that kind of talent. So our mission is to bring DevOps transformation to all of these companies, right? That’s why we’ve been hiring. And Randy Newell joined recently, so we’re very excited about that, and we have been hiring very talented engineers.

And we also released a product called nOps.io, which manages security and change management of the cloud. So over the last several years the focus has been a lot on infrastructure tooling, like Terraform and (AWS) CloudFormation. And I think we’re missing the process piece of the puzzle in this DevOps. So that’s what we’re trying to bridge, where if there’s a hundred people or ten people making changes in your infrastructure, how do you manage those changes? How do you make sure security is not an afterthought? How do you make sure every single change is documented and traced without slowing people down? So we’ll continue to innovate and help companies in the DevOps space, yes.

Shimel: Got it, got it. All right, well JT, we’re about out of time here. Thanks for coming up and appearing on this episode of DevOps Chat. Continued success with nClouds. And we’d like to see more articles from you up on devopsy.kinsta.cloud, actually. I’m sure our audience – our audience really liked the first one, and we’d like to see a lot more.

Giri: Thanks, Alan. Thanks for having me.

Shimel: But good luck. Thank you. All right. Hey, JT Giri of nClouds – CEO and founder of nClouds, thanks for being this episode’s guest on DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. We’ll see you on the next episode of DevOps Chat.

— Alan Shimel

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

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

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

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

Audio

Transcript

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

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

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

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

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

Labourey: I think so, yes.

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

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

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

Labourey: Yeah –

Shimel: Yep. Go ahead.

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

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

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

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

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

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

Labourey: Yeah, absolutely.

Shimel: – talk?

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

Labourey: – from a content – [chuckles]

Shimel: Uh-huh?

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

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

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

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

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

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

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

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

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

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

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

Labourey: Correct.

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

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

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

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

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

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

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

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

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

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

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

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

Labourey: [Chuckles]

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

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

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

— Alan Shimel

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

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

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

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

Audio

Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Edwards: Alex Honor.

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

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

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

Shimel: It’s grown up to a company.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Edwards: Thank you, Alan.

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

— Alan Shimel

July 19, 2017
DevOps Chat: DevOps, Cognitive, IoT & Blockchain

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

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

Audio

Transcript

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

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

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

Cliff Utstein: Thanks, Alan.

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

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

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

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

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

Here are some other DevOps Chats you may want to listen to:

DevOps Chat: Purpose Built Appliances for Containerized Applications with Diamanti’s Mark Balch
DevOps Chat: Developers and Security with Pete Chestna, Veracode
Patrick McClory on Building Successful DevOps Organizations

Shimel: Sure. Cliff, what do you think about that?

Utstein: Yeah. As CJ said, a lot of organizations right now are looking to build cognitive applications and what they’re thinking about often, with that, is how to move to the cloud, how to improve their overall processes within their organization, and even how to change their culture. And DevOps cuts into all of these—giving an organization a way to go through, really, a set of changes that let them develop a much tighter customer relationship, ultimately, through faster iterations in the development cycle, getting to the customer with their MBT faster, and doing it in the cloud so that they’re able to utilize all the advantages that the cloud offers them, as far as getting to the customer faster and understanding what the customer wants.

And what’s behind this, as CJ said, often, is a whole set of cognitive needs to improve their apps, based on utilizing these cognitive services, so we see it in the financial services space; we see it in health care; we see it in retail. We see it in a lot of industries, where businesses are looking to incorporate these cognitive abilities into their apps, to build the customer relationship, ultimately.

Shimel: Sure. Hey, Cliff, if you don’t mind, I wanna dig in a little bit on the whole cognitive thing. You know, with IBM, a lot of people sort of make Watson and cognitive synonymous, right? I mean, it’s the IBM brand, if you will, for cognitive, if we wanna say that. But we’re hearing so much today about artificial intelligence, machine learning, right, automation, all of these things. And automation is obviously closely tied into DevOps. Just to be clear, Cliff, when you’re talking about cognitive, first of all, it is synonymous with Watson and certainly for IBM’s purposes. Is that correct or incorrect?

Utstein: You know, I think that Watson provides us with a whole set of tools and applications providing cognitive abilities. I think, in addition to that, however, we can look at the cognitive abilities in DevOps as well, in machine learning, to determine some basic things like whether a release is likely to succeed or fail in production. We’ve got algorithms, cognitive algorithms, around that today, to help organizations figure out whether or not they’re gonna have success with a release, based on prior releases, based on patterns that we’re able to interpret within the code as well. So it means a lot of different things, Alan.

Shimel: I agree. Agreed. I just wanted to clear that up for our audience in there too and I think, you know, and, in my mind, anyway, when I look at the relationship between DevOps and cognitive and cognitive and DevOps, there’s a little bit of “chicken and egg,” in that I think cognitive can help you with your DevOps transformation and move to the cloud and everything that’s wrapped around digital transformation, while, at the same time, that same digital transformation and DevOps transformation can help you, you know, accelerate use of cognitive technologies to make your business better. So it very much is a win-win, two-way street. CJ, what do you think?

Paul: Yes. Absolutely, yeah. One is actually the building and deploying of cognitive applications itself and applying the DevOps principles; the other is using cognitive technologies within the DevOps tools themselves. Yeah. They’re both very relevant and things that IBM’s been working on.

Shimel: Excellent. Guys, if you don’t mind, ’cause time is always an issue here, I’d like to move on to the next topic, which is blockchain. So, you know, I just came off of a world tour roadshow around DevOps and other kind of issues, and, wherever we went, blockchain was incredibly hot, was incredibly popular. People wanted to know about it; people wanted to hear what the story was around blockchain. But, at the same time, I had people who were like, “What is blockchain?” Right? They didn’t understand what we meant by “blockchain” and why was it tied into bitcoin and these kinds of things and why should we care. Cliff, if you don’t mind—and I don’t know how much you know about it and, if not, CJ—can we do a level set for the audience about what we mean when we say “blockchain”?

Utstein: So, you know, I think that might be a different talk, Alan. I think, from a DevOps perspective, what we’re seeing is the need to deliver the processes, the culture changes, the tools to support developers that—especially in financial organizations, that are today looking to incorporate blockchain into their applications. And that’s really been our focus, is helping them do that quickly, securely, with governance and all the controls that a financial organization needs in order to be successful with blockchain.

Shimel: Good. Fair enough. I think that’s kind of DevOps CJ, what do you think?

Paul: Yeah. So blockchain is the Hyperledger technology that underlies offerings such as bitcoin, but that underlying technology, though, can be used to secure financial transactions, right, or different kinds of transactions around the world. So it’s driving a level of transformation in the financial industries, that lot of companies wanting to build new applications to take advantage of this technology. So that’s where, as they try to build these new applications, the DevOps techniques and tools that we’re providing can greatly help them, you know, build those applications and get those applications out there faster. So, essentially, DevOps is sort of the foundation that helps them innovate more rapidly in these new domains.

Shimel: Got it. So, Cliff, you’re the product guy; I wanted to talk a little—ou know, what are IBM’s customers doing around DevOps and blockchain? Can you give us a couple of examples? And you don’t have to mention names—you don’t have to name names, obviously—but couple of examples.

Utstein: Yeah, I think—I mean, what we’re seeing, really, is, as CJ said, in the financial sector, we’re seeing the application development really accelerate around blockchain technologies today, and what these organizations are doing is using it as an opportunity to make the changes in their organization around digital transformation. They’re doing it in the cloud, they’re doing it using open toolchains in the cloud, and, obviously, the ones that I’m most familiar with are doing it using IBM’s Bluemix, IBM’s cloud, and our continuous delivery offering with open toolchains. And that means that they’re using a set of modern tools, like Git and other tools in the cloud, to do this rapidly, and they’re iterating very quickly.

The thing that we’re hearing from our customers is that they’re making changes in production daily, that they’re getting to their customers with changes in a matter of days after the customer makes these requests. And that’s really the big difference that we’re seeing, is how quickly they can meet their customers’ needs in this space, using templates to quickly get their new developers up, using an open toolchain so that they’re using the common industry-leading tools in each of the categories around collaboration, around tests, around source code management, around issue tracking, so that they can deliver that, using those common tools, using the technologies of blockchain to deliver to the customer quickly.

Shimel: Got it. And so, Cliff, I imagine that’s a big part of your focus and, CJ, you as well, in architecting, is making sure that Bluemix and the IBM cloud—it’s still called “IBM cloud,” right, Cliff?

Utstein: It is. It’s—I mean, we call it “the IBM cloud” and it means—you know, there’re a lot of elements of the IBM cloud, but “IBM cloud” is a good moniker.

Shimel: Okay. Just wanna make sure. So, you know, part of your job, obviously, and CJ as architect, is you’ve gotta make sure these underlying tools are there in place for people, as they onboard, as they start making this migration, this transformation. And many of them are, at the same time, adopting DevOps type of customs and culture and tools to facilitate this as well. So it’s almost like you have to stay one step ahead of anticipating what these guys are gonna need.

Paul: Yes. And that’s what—now we look ahead. We look at what some of the early adopters of these technologies have observed and we’re trying to remove the roadblocks, right, both in terms of providing sample applications, quick ways to get them started with their own enterprise applications, and then, as they get started building these applications—nobody builds an enterprise application as a lone developer; they always work in a team. So we wanna make sure that we enable these teams to be productive very quickly.

And that’s where, as Cliff mentioned, we support a open-toolchain fabric, unique in the industry, and then, on this fabric, we template-ize the toolchain that these things need to get going quickly, so we can instantiate those templates within minutes and, basically, onboard a team, with both starter code for their applications, as well as the toolchain they need to get it out into production, so we’re pretty excited about that. You’ll see those kinds of capabilities show up in the way you build these Watson applications and the financial applications and the IoT applications on Bluemix and on IBM cloud.

In fact, what we tell customers is “DevOps is the way you build any application on the cloud, given that all of the infrastructure can be provisioned through APIs—you know, it’s all infrastructure, this code, on the cloud—so you don’t have to wait for your contracts to close. You can just make API code and get your infrastructure and provision your runtimes and deploy your application. So there is no other way to do it but to use DevOps.” And that’s why we are working hard to enable all of these developers to have an outstanding experience on IBM cloud, working the entire developer journey, from how they get started with the sample apps, how they get started with their enterprise apps, and how they build and deploy with toolchains.

Shimel: So let me just repeat that one line ’cause that was the money line, CJ: “There’s no other way to do it but to use DevOps.” I love it. Cliff, what do you think about this? Are you in violent agreement with CJ? Anything to add there?

Utstein: I’m in violent—oh, CJ and I are always in violent agreement, Alan. Yeah, we’re seeing—and I think, as these companies move to the cloud, as they take advantage of Watson and blockchain and IoT, it’s critical that they adopt DevOps practices or else they’re unlikely to succeed. It’s gonna take them much longer to get to market, they’re gonna do it with less customer satisfaction, lower quality, and they know it. I mean, the data’s in. I read it on your website, Alan. Go to devopsy.kinsta.cloud; you’ll see.

Shimel: Absolutely. Guys, we’re kind of running a little bit low on time. We have a few minutes left. I wanted to talk—we had IoT on our list and I don’t wanna shortchange you because it’s important. You know, IoT, to me, guys, is—I mean, there was so much hype around this, let’s say, a year or even two years ago. We went suddenly from IP4 to IP6 because every refrigerator’s gonna be connected, but it’s not just the refrigerators and toasters, right? It’s all of the little gadgets and how many IoT devices are on our cars, even if we don’t own a Tesla. How many—you know, I signed up for a contest yesterday to get one of those free RFID tags that you can put on your keychain so you won’t lose your keychain anymore, and it’ll show you where it is or your wallet or anything else you wanna find. And, to me, you know, even in my house, we’ve gone smart home and I’ve got all these IoT devices now that I can control from my phone. So the hype is real, but, first of all, how much IoT are you guys seeing with the cloud and in the IBM customer base? Either one of you.

Paul: Yeah. I would say the IoT scenarios—you mentioned smart home as an example, but connected cars are another big driver because now you can buy cars that have built-in WiFi plans, right, that are paid for, for some number of years, by the manufacturer itself. So you can see maps and understand, for example, what the traffic durations are or there’s burglars in an area, even as you do navigation on your car navigation system.

So lot of these connected devices both pull and push data to the cloud, and that is where a lot of the data collection and analysis applications are actually being built out, to support these devices on the edge, because lot of the compute that backs them up is out in the cloud, right? And so, again, all of these are brand new applications that nobody had before, so they have to build it and iterate on it rapidly and get it out and get feedback from the users and continue to improve it. And there, again, all of the practices and the toolchains are very relevant to any of the teams building the IoT applications.

Shimel: Sure. Cliff, what do you see on your end?

Utstein: Yeah, I mean, as CJ is saying, I mean, automative is a big driver right now of IoT and BMW’s CarData platform was created to run on the IBM Bluemix cloud, in fact.

Shimel: Oh, right.

Utstein: That was just announced two weeks ago. And it really gives the new platform access to IBM Watson IoT capabilities, so that’s a big deal in the space and they’re talking about 8.5 million BMW customers globally taking advantage of this service, and it’s really about data. I mean, as we talk about IoT, it really comes down to big data and needing a cloud to manage the big data and needing practices like DevOps, if we tie it back to DevOps here. It’s really about practices and giving developers the ability to take advantage of these practices to build that relationship with the customer so that the customer can make sense of that data ’cause that’s what the cloud can do best.

Shimel: Yeah. I mean, my sense, guys, is that, with all—you know, CJ, you mentioned a few applications. Cliff, you literally put the rubber on the road with BMW relationship—you’re right. But I still feel like we’ve barely scratched the surface between how IoT—connected devices, if we will, interacting with the cloud, are gonna change the fabric of our lives. Right? And I think we haven’t even touched on the medical aspects of it, when you have nanotech running in your body, reporting back somewhere to the cloud about your vitals and your bodily functions and so forth. I mean, it’s gonna change things.

But, Cliff, you hit on something that I think is really important about all of this. Underlying all of these things is big data and big data analysis and analytics, and that’s where cognitive becomes the game-changer, in my mind, anyway. I mean, what do you think, Cliff?

Utstein: Yeah, I think that’s it. I mean, I think IBM’s cloud bringing together the platform for big data and cognitive together, with a set of DevOps processes, I mean, is truly differentiated.

Shimel: Absolutely. Guys, you know, I promised you 15 minutes; here we are at 22. So we’re gonna need to wrap things up here, but, you know, each one of these areas—cognitive, blockchain, IoT—probably, we could have done a podcast on each of ’em, but I’m glad we were able to hit what we did. Maybe we could come back on in another time and part-two this and dive a little deeper ’cause I did wanna touch on the connection between, let’s say, cognitive and IoT, and I think we’ve just scratched the surface. But, for now, we’ll call it a wrap on this edition of DevOps Chat. Cliff, thanks so much. I know it was your first time on; I hope we didn’t scare you away and you’ll come back and join us again.

Utstein: Thanks, Alan.

Shimel: Thank you. CJ –

Utstein: Would love to.

Paul: Thank you, Alan.

Shimel: CJ, always a pleasure having you on, my friend. I look forward to seeing you soon.

Paul: Thank you, Alan. It was a pleasure.

Shimel: All right. CJ Paul, Cliff Utstein, IBM’s cloud and Bluemix team. This is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Thanks for joining us and we’ll see you soon—or listen to you soon, on another DevOps Chat.

— Alan Shimel

July 13, 2017
DevOps Chat: Developers and Security with Pete Chestna, Veracode

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

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

Audio

Transcript

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

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

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

Chestna: Thanks.

Here are some other DevOps Chats you may want to listen to:

Node.js Becoming More DevOps-Friendly
DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet
DevOps Chat: Why Real Transformation Starts with Culture, Bryson Koehler and Shelbee Smith-Eigenbrode, IBM

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

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

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

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

Chestna: Right.

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

Chestna: Oh, absolutely.

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

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

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

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

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

Chestna: Yeah.

Shimel: Excellent.

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

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

Chestna: Right.

Shimel: It was some –

Chestna: It was from the Puppet report.

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

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

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

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

Shimel: Yeah. [Laughs]

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

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

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

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

Chestna: Yes.

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

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

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

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

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

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

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

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

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

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

Chestna: Sounds great.

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

Chestna: Yes.

Shimel: Are you speaking at Black Hat, Peter?

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

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

Chestna: Yes, sir.

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

Chestna: Thanks. I appreciate your time, Alan.

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

— Alan Shimel

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

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

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

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

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

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

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

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

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

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

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

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

Shimel: Mm-hmm.

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

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

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

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

Shimel: Got it.

Menachem: Does that answer your question?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Menachem: Thank you very much, Alan.

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

— Alan Shimel

June 23, 2017