devopsy.kinsta.cloud

Category: Podcasts

DevOps Chat: The CD Foundation, with CloudBees’ Kohsuke Kawaguchi and Tracy Miranda

A new foundation, the CD Foundation, has been formed under the auspices of the Linux Foundation to serve as the home base for a vendor-neutral movement committed to making it easier to build and reuse DevOps pipelines across multiple continuous integration/continuous delivery (CI/CD) platforms.

The first projects to be hosted under the auspices of CD Foundation includes Jenkins, the open source CI/CD system, and Jenkins X, an open source CI/CD solution on Kubernetes. Both were developed by CloudBees. Netflix and Google, meanwhile, are contributing Spinnaker, an open source multi-cloud CD solution. Google is also adding Tekton, an open source project and specification for creating CI/CD components.

Founding members of the CD Foundation include Alauda, Alibaba, Anchore, Armory, Autodesk, Capital One, CircleCI, CloudBees, DeployHub, GitLab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP and Snyk.

In this DevOps Chat we speak with Kohsuke Kawaguchi (aka KK), founder of Jenkins and CTO of Cloudbees, and Tracy Miranda, open source community director for CloudBees. They give us the insight behind the CD Foundation and what the future may be for Jenkins, JenkinsX and CloudBees.

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

Transcript

Alan Shimel: Hello everyone. It’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat is about some big news that came out in the DevOps continuous integration/continuous deployment world, CI/CD. That is the founding of the CD Foundation and it’s part of the Linux Foundation. It was announced just this afternoon. I’m happy to be joined by a couple of folks from one of the founding members—really one of the pivotal founding members of the CD Foundation, CloudBees. From CloudBees, joining us, joining us today is Tracy Miranda, who is director of open source community at CloudBees, and none other than KK himself, founder of the Jenkins Project and community as well as founder and CTO of Cloudbees. Kohsuke, Tracy, welcome to DevOps Chat.

Kohsuke Kawaguchi: Thanks for having us again.

Shimel: Kohsuke, it’s always a pleasure to have you. Tracy, I know you’re new to this, but thank you for joining with us.

Tracy Miranda: Yeah, [inaudible].

Shimel: Guys, big news today. Linux Foundation starts the CD Foundation. CloudBees is one of the founding companies, and if I’m not mistaken, a board member of CD Foundation as well. Is that correct?

Kawaguchi: Yeah, exactly. We are part of what – I think 20.

Miranda: Yeah, I think we’re up to 23 members now.

Shimel: I think it might have been 25.

Miranda: Wow [chuckle] I think it’s continuously growing.

Shimel: It’s funny. I spoke to a few companies today after the announcement. They mentioned that they’d like to join in it. That’s for them. I’d like to understand and maybe, KK, this is a question for you. What was the motivation to turn Jenkins and Jenkins X – we’re talking about two significant projects – over to this new foundation and to the Linux Foundation?

Kawaguchi: From the Jenkins – I have multiple hats to wear in this, but from the Jenkins project perspective, a key part of it is we wanted to create this level playing field that creates – that accelerates the innovation in Jenkins family. The Jenkins family as you know, it’s been benefiting pretty much everyone in every organization, and there are a lot of companies with an eye on Jenkins. We want to drive them more into the project. We move the project forward together. In that way, I think we can do it faster. In case of Jenkins X, it’s been critically designed on a number of projects that’s coming out of the CNCF, which is a sister foundation that is also under the Linux Foundation. It made a lot of sense we’d be bringing these projects closer so that we can again collaborate faster. So those are, I think, very convincing obvious benefits for two projects.

Now the CTO of CloudBees, CloudBees has been the biggest contributor of behind the Jenkins project. This move made a lot of sense for us as well, because one, our customers rely on a lot of open source projects and ecosystem. When those foundational resource projects that’s driving is strong, then obviously that benefits CloudBees and our customers. I think that’s a fairly obvious move for us as well. Also importantly, we – well, I, talk to a lot of people in the – our customer and prospect organizations and those technical people understand the need and the benefits that the objectivity really brings. I often see them struggling while the rest of the organization around them. Here, I talk about things like money, people, and time to invest in these efforts. It make the necessary business impact.

I feel like a part of the role that I’m really looking forward for the CDF to play is to advocate the practice of continuously, elevate it beyond the technology practice. Again, like the CNCF for cloud-native, thereby we can make a bigger impact in the world. That’s the kind of thing a single vendor cannot very easily do because people automatically assume the intention behind these things, or a pitch behind them. Open Source foundation, there’s multiple vendors, and also the end user companies like _____ and _____ adds a lot of credibility and authenticity to that message. For all of these reasons, I think it’s kind of a no brainer, a win win win across the board. That’s how I think about it.

Shimel: I think that’s a great way of looking at it. Tracy, let me ask you, you’re the liaison to the open source community. In this case, we’re really talking about the Jenkins community and Jenkins X. How is this announcement – it’s kind of new still, but what’s been the feedback from the community on this?

Miranda: Yes, it’s been really, really positive. We’ve been talking to the Jenkins community, well, the Jenkins board members, Tyler and Kohsuke, the kickoff conversations over a year ago. Since I’ve come in as well, we’ve been keen to get everybody involved with how this would shape up. We’re hearing lots of exciting things. Some things we hadn’t even predicted at the beginning. So for example, Jenkins has a very emerging and very strong and enthusiastic Chinese community. They are super excited about using CDF as a way to really expand in China. I think we can look to that for new areas we want to expand into. So yeah, on the whole, very positive. Lots of enthusiasm which is fantastic.

Shimel: Absolutely. As a matter of fact, I’m somewhat familiar with the Jenkins community in China. One of our partners held the Beijing Jenkins Day while I was out there last year. So I had a chance to meet a lot of those folks firsthand. It was a very enthusiastic group. They’re doing great things there in DevOps and CD as well. I’m sure it’s been used as well as Jenkins X. Actually, one of the founders of the Jenkins X project was presenting there that day. He was in from Australia. It was very, very well received. Back to this, both for Tracy and KK, one of the things I think people really admired about CloudBees was it wasn’t the usual vendor open source project manager relationship.

So many of these open source projects that are managed by a single vendor tend to be run for the sole benefit of that vendor whether it be OpenCore or Razor-Razorblades kind of thing. Decisions are made for the benefit of the commercial vendor, oftentimes at the expense of the community. CloudBees was always above that. All these years there was an independent board. There was independent steering and governance of the Open Source community and project. With that already in place, KK, does that negate some of the reasons why you would need a separate foundation, or that just accelerates it?

Kawaguchi: Yeah, so thanks for the nice words. We’re already proud of the way we participate in Jenkins project. I think there are two factors to that. One is number of people who founded CloudBees. They all come from open source background, the _____ folks, RedHat folks. We share a lot of – it’s like a common body. And that really played a critical part in recognizing, understanding how open source community works. The other important part to call out is Jenkins project is not owned by CloudBees. It is an independent project with its own decision-making process. This project, mind you, it came out of the drama with – well, a certain company. I won’t name names.

Miranda: [laughter]

Kawaguchi: So I think the people in the community felt really strongly about their independence. So we discussed it. So, in moving to CDF, many – well people are outside CloudBees, they also continue their _____ CloudBees. They’re also very anonymous desire and preference to come over to CDF because they see it as the next step of the governance to ensure this level playing field, which I touched on a little earlier. Then I think that’s been – that was seen as very valuable characteristic. I think the CloudBees has done good things over the past year _____ the project. I think it’s time to also codify and turn it into something more stable and fundamental. I think that’s what this move to CDF signifies.

Shimel: I think that’s true. I think there’s another element too, KK. When we look at the history of Jenkins, when something is so successful, you don’t see many contenders. That was true with Jenkins. When Jenkins burst on the scene – we don’t have to go into the history of it, but Jenkins burst on the scene, and it quickly became the dominant CI and then CD tool of choice, not only for the DevOps community, but for the software developing and ops communities. Everyone used Jenkins. Recently, in the last year or two, three years, we’ve seen other contenders coming up, many of them commercial.

Some of them have an open source, open core, kind of program business plan, but nevertheless, people had this, “Well, Jenkins is older, or it’s yesterday. This is tomorrow.” I think by putting it in a foundation like this, it guarantees a tomorrow. It’s the old, “So many eyes on the code, it has to be better” story. With so many hands in the pot, it has – it’ll accelerate faster. So that’s a good thing. I feel like we’re neglectful though. We should mention beyond Jenkins and Jenkins X, there was some other great software programs that were contributed to the CD foundation today, correct?

Miranda: Yes, that’s right. Would you like to hear a little bit more about those?

Shimel: Yeah, please.

Miranda: We’re super excited. One of the other projects is Spinnaker, is what Netflix originally put together for continuous delivery. That is a well-known, a well-loved project in this space. We were really excited they bought into the vision and wanted to be part of it. Then the other project, last year Google announced the Knative serverless platform. As part of that project, there’s a build and pipeline side of it which has been renamed to Tekton. Tekton is the pipeline and build part of – behind Knative. What’s really exciting about this project is that we’re looking as part of the vision of CDF to really focus on integration and sharing concepts and making tools work together. Tekton will be the pipeline engine, set the definitions for which Jenkins X are going to evolve to. Spinnaker are going to look at it too, and for Jenkins’ next generation pipeline, there’s lots of exciting things in the work. Just really excited about all the possibilities coming up.

Shimel: Sure. We should mention both Spinnaker and Tekton were contributed by Google.

Miranda: Google and Netflix for –

Shimel: And Netflix yes, for Spinnaker. But that’s not all. Once a technical oversight committee is formerly introduced, there may be other projects that are – come under the CDF management as well, correct?

Miranda: Yes. Absolutely. I think one of the things we outlined in the charter is we want to focus on the entire software delivery life cycle. We want to have a whole set of complimentary projects. So we’re looking – there’s some really exciting projects in the world of mobile and other areas as well. It’s not just cloud. So lots and lots of exciting projects out there. We look forward to welcoming and onboarding those as we develop, and as we get up and running properly.

Shimel: We should also – I just wanted to mention that some of the other companies involved as founding members of this CDF are Alibaba, Autodesk, Capital One, CircleCI, CloudBees, obviously, DeployHub, GET Lab, Google, Huawei, JFrog, Netflix, Puppet, Red Hat, SAP. These are household names out there. This really is a heavyweight list of contributors, and I think guys, that that really talks to just how important CI/CD has become in the modern software factory.

Kawaguchi: Like I said, it’s kind of on the cusp from growing from just the technology things to more bigger business impact. It took CloudBees all along, and so I’m really excited that this mission, this sense of passion is all shared by so many more companies. I think it makes the message a whole lot more critical.

Shimel: Here’s another flip side. As this frees up CloudBees to really focus in on the commercial side of things. Though you weren’t – CloudBees didn’t manage Jenkins. The community and the Jenkins community managed itself. CloudBees played a – obviously it was a big role helping – making sure – KK, you’re wearing two hats with that. Now that CloudBees is freed from that, what do you think we’ll start seeing from CloudBees going forward?

Kawaguchi: Actually, we are doing more than ever in open source. A number of key folks behind Nginx is at CloudBees _____. So just to make sure that this isn’t all a move by _____, trying to wash our hands away from it. In fact, it’s the opposite. At the last time also, CloudBees is getting bigger. We are working on a number of the products and services. So I don’t really see those things as mutually exclusive. I think everyone at CloudBees understands that those are both important parts of our business.

Miranda: Yeah, and if I add to that, well, this one specific example, the DevOptics project, which focuses a lot on analytics, and these key measures you’re doing your software delivery. That’s one area where CloudBees is going to do a lot more and you’re going to see a lot more, and it’s pretty exciting going up to that next level.

Shimel: Excellent. I would imagine you would. Tracy, if you don’t mind, this is going to be a change for you and how you deal with the open source community, or you think not really, not too much?

Miranda: No, absolutely. I think it’s going to be quite different. We’ve got lots of different people working together. I think that’s what makes it really exciting, just having the different perspectives, the different ideas. I always say like with open source, what I’m most excited about is the unexpected things that you don’t really know what they are until they happen, the innovation, or the two people getting together and saying, “Hey, let’s take things in this direction.” It’s so full of possibilities that it’s really exciting.

Shimel: I think it will be, and I think it’s going to be for sure. You know what, I haven’t read – who particularly from CloudBees is going to hold the board seat in the CD foundation? Has that been announced or decided?

Miranda: So I’ll be representing CloudBees at Board of Directors, but also Kohsuke is heading up the technical oversight committee, which means he will also be at the board level. We’ve modelled a lot of the charter and foundation rules off the CNCF where it made sense.

Shimel: Fantastic. That is really good. What about some of the other folks who are on the board of the Jenkins community board? People like Tyler and some of the other folks? Will they be – what will be their involvement going forward, if you know?

Kawaguchi: I think the charter will define the structure. It’s just got launched and we will, I think, in the coming days we will have people’s names and so on. I just don’t want to give the wrong information, but Tyler, for example, he’s been pretty instrumental in making this happen. So I expect him to stay involved in this going forward in some shape or form.

Shimel: Absolutely. I realize it’s only announced today. You don’t have all the answers, but I thought I’d ask. So final question because we’re running low on time here is one of the – you called the CNCF a sister foundation, it would be hard to argue that hasn’t been a really successful effort by the Linus Foundation, and not just Kubernetes. Kubernetes seems to be the star pupil, or star favored child. There’s a lot of projects within CNCF that are really, really doing well. CNCFCon along with KubeCon is – to me, it was the most exciting event I’d been to certainly within the last six months, certainly since Jenkins World. Will there be a similar type of event now for CD Foundation? Or maybe you pitch one grand tent with CNCF for one big conference? Any ideas on that?

Miranda: Well, first thing we have in place is that we are going to hold our very first continuous delivery summit. We’re going to co-locate that with the new KubeCon which is in Barcelona.

Shimel: In May.

Miranda: That’s right. Yeah, getting going quick. That will be our first opportunity to bring a lot of contributors together, a lot of the end user community as well. We just love the projects in CNCF. We want to continue collaborating closely with those folks. I think this will be a great first event. We did just hear today that there’s something like 12,000 people expected at that event in Barcelona. Big, big fans of CDCF.

Shimel: Yes. I will be there – we’ll be there doing videos. Hopefully, we’ll get to, Tracy, meet in person, maybe do some video interviews there in person.

Miranda: Yeah, that would be awesome.

Shimel: Yeah, that would be great. Then, we’ll – I forgot when the next one. Well, after that, the Shanghai in July, and then in the fall is KubeCon back in North America. Will this be an ongoing collaboration or is that – after that, you might do your own?

Kawaguchi: We don’t know that yet, I think.

Shimel: Still to be decided. All right, well guys, congratulations first of all, on all of the new today. This sounds just so god darned exciting. It’s good stuff. Kohsuke, what can I say, man? You just keep doing it. Congratulations. Keep it up. Tracy, congratulations. I guess we’ll be hearing a lot more about the CD Foundation in the months and year ahead.

Miranda: Yes, absolutely. Thanks so much, Alan. This has been wonderful.

Shimel: You know what? I sound like Colombo. One last question. You’re probably too young to remember that, but anyway, why not CI/CD Foundation? Is CI becoming passé, out of style, we don’t refer to it? Or we’re just so focused on CD? Any thoughts on that?

Kawaguchi: The practice that surround the continuous integration is still very much there. I just think of it as frontier moving on, and so therefore the concept is encompassing more and more. When we say continuous _____, so the _____ includes all of the things we talked about as CI. It just expanded into something bigger is how I think about it.

Shimel: Yeah, all right, fair enough. Guys, again, thanks so much, Tracy, KK. Kohsuke from CloudBees on the announcement of the Linux Foundation setting up the CD Foundation and Jenkins, Jenkins X part of it. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to a minute of DevOps Chat.

— Alan Shimel

March 21, 2019
DevOps Chat: Doing Agile, with AgileCXO’s Jeff Dalton

Agile has a bit of a longer history and subsequent maturity than DevOps. Despite this, how can an organization say that it is in fact an “agile organization”? What does that even mean?

Our guest on this DevOps Chat is Jeff Dalton, founder of Broadsword consulting, author of “Great Big Agile” and founder of AgileCXO. Jeff shares with us his latest venture, which is building AgileCXO into a worldwide movement to certify that organizations are, in fact, practicing Agile with best practices. Have a listen.

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

Transcript

Alan Shimel: Hello, everyone, it’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat is, I think, gonna be a good one. We have with me author, founder Jeff Dalton of the AgileCxO. Jeff, welcome.

Jeff Dalton: Good morning, Alan. Thank you for having me, sir.

Shimel: Absolutely. My pleasure having you. Talking off mic, we both lamenting freezing down here in Florida, but, you know, first world problems. It’s gotten into the 50s; we’re breaking out the cold weather gear.

Dalton: Yeah. Right?

Shimel: There was a time in my life where, if you told me it was 50s in January, February, I’d be out running around.

Dalton: Go to the beach?

Shimel: Yeah, pretty much. But, anyway, such is life when you move to Florida, Jeff. But let’s talk a little bit about the AgileCxO. First of all, let’s assume some folks in our audience are not familiar at all with it. Talk to us. What is it?

Dalton: Sure. AgileCxO.org is an organization that we started about two years ago and it was based on the notion that leaders really struggle with how to successfully create Agile culture in their organization and it was based on a series of about 200 assessments we did of Agile organizations to try to really figure out why it wasn’t taking hold in the way leaders wanted it to. And the conclusion we came to was really simple, really, is that Agile leaders weren’t being Agile themselves and they really didn’t know how to be. They need help with that, so there’s lot of reasons for that and we talk about that in the book, “Great Big Agile,” but that’s how we started about two years ago.

And, since then, we’ve developed a series of models for performance and for evaluation and a series of training courses. We have partners in China and Japan and India and the US now, delivering these services to their customers, so we’re pretty excited about it, and, now that the book’s come out, we’re even more excited about it.

Shimel: Absolutely. So, Jeff, for some of our folks out there, they hear people say, “I wrote a book,” right? And you know what? I’m blessed to have a lot of friends who’ve written books; I’ve contributed to several books. And people say, “Oh, yeah, that guy wrote a book.” They don’t really understand what goes into writing a book, though. I mean, right? I mean, it’s one thing to write a blog article or something like that. Writing a real book is work, though.

Dalton: It sure is.

Shimel: Share with our audience a little bit, what was the effort required here _____ _____ —

Dalton: That’s a great question. I’ve never been asked that, but it’s funny. I started my book with the—you know, you have the acknowledgements in the front of it and the very first line was “Writing a book is much harder than I thought it was.” [Chuckles]

Shimel: Yeah, it is. No, it is. I mean, there’s no doubt.

Dalton: You know, I’d written a lot of articles, lot of long articles. You know, I write a lot for Cutter IT Business Journal and for Better Software magazine and per week. And I’ve written quite a few articles in my life and I’ve written quite a lot for e-books, but what I really wasn’t prepared for was the sheer volume and effort associated with telling the story in completeness. You know, it’s one thing to kick one idea out in a blog post or to kick a series of ideas out and explain ’em, but to really explain a system of ideas and provide supporting information and research and really tell a convincing story, from start to finish, is a massive effort that I didn’t even do alone. I had help. I had—you know, my wife’s an editor and she really helped out, and I had other people on our team really help, providing me with information and reviews.

And that doesn’t even consider the publisher, who kept coming back with demands for more information and better clarification and really kept me on track there. And then there’s artwork and covers and indices. And I know, at the very end, they’re like, “Oh, you need a glossary”; I’m like, “Oh, okay.” So it’s a massive, massive effort, but it’s also a really cool effort because what I’ve learned from writing the book, one, is that you don’t really know what you’re talking about until you’re forced to flesh it out in writing.

Shimel: Yeah. For sure.

Dalton: And it’s really helped me working with my customers and clients because I’m able to really articulate what I think. And this is important because the book is about a new idea that people aren’t talking about that much. And a lot of people are talking about Agile—a lot of people—and there’s a lot of fantastic books about Agile. We didn’t wanna write another one. We thought that Ken Schwaber’s book on Scrum is beautiful and doesn’t need much elaboration and there’s books on DevOps that are very well done, and we didn’t really wanna write another one of those. I wanted to write about something new, so thinking through that entire story required a lot of effort and time and much more than I expected, but it finally comes together. At some point, you get in a groove and then it just becomes a mission. And we completed that mission in October, so.

Shimel: Good for you—

Dalton: A book came out the other end, so it’s pretty exciting stuff.

Shimel: Absolutely. But, you know, what’s kinda different in your case, Jeff, is the book really serves as the bible, the how-to, the map of this whole AgileCxO, as we were talking about. Agile in a vertical, I think, is how you mentioned it. Agile in a vertical way, not the usual horizontal, if you will.

Dalton: Right. Yeah, one of the things I talk about in the book early on is really trying to position the different industry models a little bit more succinctly because we hear about process models or behavioral models and frameworks, and there’s a lot of ambiguity in the industry about the differences between these things. “What’s the difference between Scrum and Agile?” is something you hear people talk about a lot and “What’s the difference between ISO and CMMI and PMBOK and all these different techniques and models out there?” And we categorize these things into three different categories in the book: what we call “why-ability” models—why are we doing stuff?; “what-ability” models—what am I supposed to do?; and “how-ability” models—how am I supposed to behave?

So you take something like an ISO or a CMMI or a PMBOK, these are squarely what-ability models—you must do these things; there’s a list of things that you’re supposed to do—but gives very little guidance on how to do it, what kind of behaviors are necessary. And a lot of the Agile frameworks are really great why-ability models—you know, “These are Agile values and here’s why you should do these things”—and they’re very light on the “what” because they wanna be more empirical and they wanna have teams learn and improve and change, as it makes sense. But there isn’t a lot of detail for a leader to say, “How do I make an Agile organization?”

So we coupled that with the notion that scaling Agile is really about scaling vertically, from teams up to senior management, not so much scaling horizontally, which is what we see with things like SAFe or LeSS. These are all great models and they’re necessary models, but the conversation’s really been focused on horizontal scalability, but nobody’s really talking about vertical scalability and the changing of leadership. Though we talk about being change agents and changing companies, when we do Agile transformations, but what we’re not doing so well is changing leadership.

Shimel: No.

Dalton: And that’s the primary impediment. I mean, if you look at any major study, like the VersionOne study—people talk about that one a lot—they’ve been saying for years, they’ve been raising this flag for years, that leadership is an impediment. And Cutter IT Business Journal just did a whole series of articles—I wrote one of them—about the problems with Agile leadership, so nobody’s really been addressing it, other than in the trade magazines. So we decided to write a book about it, and we’ve had a lot of experience. I spent a lot of years at Ernst & Young, doing leadership coaching, and we’ve had a lot of experience working with senior management, so we said, “Hey, they need help understanding this,” and so we wrote a how-to book for them. And that’s what it is. It’s called Great Big Agile and it’s actually filled with lots of pictures and it’s in color and it’s really designed for a senior manager to use as a reference.

Shimel: Fantastic. And we’ll get into where the book may be available, how some of our listeners listening in, if they wanna grab a copy, where they can, but I think the other thing I wanna convey to the audience, Jeff, is that this book doesn’t exist in a vacuum. It exists—

Dalton: Right.

Shimel: Right? It exists within the larger universe, as you mentioned, of other Agile books and DevOps books and a lot of, as you call them, these horizontal frameworks and so forth, but the book itself has kinda served as, again, a blueprint for an entire school of thought, if you will, that is now taking shape worldwide, with people who are offering training and coming in and assessing organizations and helping them to achieve this type of vision, right?

Dalton: Right. Well, you know, consultants, especially management consultants, have, for years, been talking about leadership reengineering and reengineering the organization. If you’re reading anything from Peter Drucker or any of those guys, they’ve been talking about it for years. And I remember, the decades I was with Ernst & Young, years ago, we always talked about this and we always did engagements, working with customers, to help improve leadership performance. What we didn’t have is a model that describes how to do it. We sat down with leaders and we said, “Well, who do you wanna be?” and, “I’m a smart guy. Let me help you.”

In a lot of ways, we need the same types of models and assessment and training that we’ve been championing for lower-level teams—Scrum certification, for instance, SAFe certification, DevOps cert and training. These things are considered normal coursework and certifications for the average worker now. We don’t have anything similar for leadership, and that’s what this model is all about, is giving leaders a chance to really learn and have a how-to model for how to improve performance and to get their whole organization certified so that they can be known as a really progressive Agile organization.

Shimel: And we spoke off mic, Jeff—you know I’m one of the co-founders of the DevOps Institute—so I have more than a little bit of experience and insight into what it takes to have sort of a worldwide network of people who are offering training, education, assessments, based upon, you wanna call it, “curriculum” or “knowledge,” that you’ve sorta codified, if you will. That’s a big job, right? It’s more than just Jeff Dalton.

Dalton: Right.

Shimel: And so share with us, if you can, a little bit, what’s the organization like?

Dalton: Sure. Well, we have a team. This didn’t start from scratch. I own another company called Broadsword that’s been around for almost 20 years and we’ve been reasonably successful in the performance improvement market. We work with various models, including Agile frameworks but also CMMI and ISO and PMBOK and Scrum and XP and SAFe. And we work with all of those models and we work with companies—largely, federal government contractors of pretty good size—so we have a lot of experience working with Fortune 500 companies all over the world. We have customers in China and Hong Kong and India and Japan and the US and then some in Europe and South America. We’ve been doing this pretty successfully for about 20 years and we’ve built a large network of CEOs and leaders, especially CIOs and CTOs, of organizations all over the world. And so that’s where we started, and so Broadsword has 15 people that have been focusing on other models and other training, by other organizations, for years.

And so what happened is is we were doing some assessments of couple of really large companies, two years ago, and we realized that the real impediment was this whole notion of vertical traceability, we call it, or vertical expansion of agility from teams up to senior management. And we started noting that with a lot of our clients. And so we said, “There’s something needed here. The industry really needs help with this, so let’s create a model that we can use with our clients.” Then we started getting calls from other companies, saying, “Can we use your model?” and other consultants around the world, and so we started—so it started organically, this network of a couple of hundred CEOs and CTOs and CIOs, which is where we came up with the name of the organization—“CXO.”

And so it really happened organically because of demand, so what we did is we shifted about half of those folks over to the organization to work on that and we hired a few folks. We have a chief operating officer; we have a CTO; we have a partner manager; we have model developers. So we have a team of folks that are really dedicated to this, to make it work, and we’ve outsourced things like marketing and bookkeeping and all that kind of stuff, so we can focus on the important things. But it’s a group of really senior, very experienced people, so we’re really pushing to try to make it happen.

Shimel: Yep. Hey, Jeff, we’re starting to run short on time, so I wanna start putting a bow around some of these things.

Dalton: Sure, yeah.

Shimel: First of all, people listening out there—and our audience is pretty diverse, worldwide, but can you give me either the one big reason, or the top three reasons, why AgileCxO is something they really need to take a look at?

Dalton: Sure. Well, the biggest reason is that agility and self-organization are unavoidable—they’re coming—and it has nothing to do with Agile. Interestingly, Agile and DevOps are a reaction to a worldwide trend. If you take a look at the Gallup study that’s done every year on people’s faith in leadership and institutions, what clearly is being defined in their study—and it’s a worldwide study—is that people are losing faith in traditional leadership. They’re losing faith in the kind of leadership that Harvard and Stanford are pumping out every day; they’re more interested in self-determination and self-organization.

This is happening in banking, education, software development—the military has even suffered from this or if “suffering” is the right word. All kinds of industries, universally, are moving, more and more and faster and faster, towards this notion of self-determination and self-organization. It’s a worldwide trend. And you see a lot of chaos in the world and that’s really what it’s about—it’s about a massive upheaval in the traditional norms of leadership.

And so it’s inevitable that, if you wanna maintain young performers that are of high quality and you wanna have a successful organization long term, that you’re gonna need to adopt Agile culture, top to bottom, in your organization. So you’re gonna have to completely reengineer the way you run your companies, or else you’re just not gonna be able to attract talented workers. So that’s just inevitable. The data tells us that that’s coming, so that’d be the number one reason to look at this.

The second reason is that leaders are really struggling with understanding what Agile means, what self-organization means and how to actually achieve it. And they’re getting a lot of pushback from the lower levels of their organization to be more Agile, but, if you’ve ever worked on an Agile or a DevOps team, you know that, the further upstream you push, the harder the swimming gets. There’s a reason for that—we call that an “organizational type mismatch,” where I’ve got a command-and-control infrastructure, from CEO down to basically supervisor level, in an organization, and then I’ve got all these people saying, “I wanna self-organize and be more Agile.”

So that clash of cultures is extremely energy-dependent—in other words, burns a lot of energy in your company—to the point that your costs are overcoming your profits. So that would be the second reason to do it, is it’s a how-to guide for how to avoid that cultural, organizational type mismatch.

And, finally, I think the third reason is that it helps employees be a lot happier, and happy employees are more productive and happy employees stick around longer and happy employees, team members, are happier to work there and create less friction, less resistance. So it’s good for everybody. So all good reasons to check out the book, to check out AgileCxO. And if you are a consulting firm or a company that really wants to help companies achieve these three goals, become a partner and join us and join us on our mission. We’d love to have you.

Shimel: Very cool. Jeff, last part—and it really segues off what you just said—where can people get more information?

Dalton: Well, two places that I would recommend you do that. One, you can buy the book on discount at Amazon, just “Great Big Agile”—go to amazon.com. You can also buy it from any other book retailer, if you like Barnes & Noble better, or from Apress—apress.com is who distributes it for the publisher—but Amazon is probably everybody’s go-to for where to get the book, so I’d definitely take a look and read at that.

And then agilecxo.org. If you go to agilecxo.org, you’ve gonna have at your fingertips samples of the model, lists of the training, videos to watch. We do our own podcast, similar to yours, Alan—the Agile Leadership Podcast. And what we do there is we interview CIOs and CTOs of state and government, primarily, around the country, so we’ve got Texas and Kentucky and Florida and Michigan and Wisconsin and CIOs from really large, 2,000-, 3,000-person IT organizations that are trying to adopt Agile. And we get their perspective and the things they’re struggling with at the Agile Leadership Podcast. So all that’s available at agilecxo.org and feel free to stop by.

Shimel: Excellent. Jeff, we’re about out of time. First of all, thank you very much for sharing with us today the insights and more about AgileCxO. Continued success with it. We’ll watch it go and maybe we have you back on the show, couple months, and see where things are.

Dalton: Thanks. I would appreciate that. And, while we’re talking about that, Alan, we’d love to have you on our “Agile Leadership Podcast.”

Shimel: Any time. Just let me know when and a dial-in or log-on and I’m there. Hey, stay warm down there.

Dalton: I’m doing my best. I think I may have one degree on you down here.

Shimel: Yeah, maybe. But it’ll warm up soon enough and I’ll have to get—you know, I like _____—usually, I go to Islamorada fishing.

Dalton: Right. Yeah.

Shimel: Key West partying and Marathon somewhere in between, so—

Dalton: _____ not gonna lie, we do a lot of fishing around here.

Shimel: Oh, I’m sure you do; it’s good fishing. Anyway, Jeff Dalton, the AgileCxO organization and author, thanks for being our guest here today on DevOps Chat. And this is Alan Shimel for devopsy.kinsta.cloud and DevOps Chat. Have a great day, everyone. We’ll catch you soon on the next DevOps Chat.

— Alan Shimel

March 15, 2019
DevOps Chat: AppSec and DevSecOps with Contrast Security’s Jeff Williams

I have known of Jeff Williams in the security industry for more than several years. He is a well-respected thought leader in AppSec and OWASP. I finally got a chance to catch up with Jeff and talk with him about Contrast Security, the company he co-founded and how it is helping.

In this DevOps Chat, Jeff and I discuss the state of application security and how AppSec fits into the larger DevOps realm. Jeff’s a great interview with lots to share.

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

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and we’re here for another DevOps Chat. Today’s chat has a decidedly security bent. I’m happy to be joined by Jeff Williams, CTO and co-founder of Contrast Security. Jeff, welcome to DevOps Chat.

Jeff Williams: Thanks, Alan. Good to be here.

Shimel: Hey, my pleasure. So, Jeff, you know, as we were talking off mic, this is the first time we’re kinda interviewing anyone at Contrast. Why don’t we—I think it’s only fair we start off with sort of, let’s give our audience a little background. Who and what is Contrast Security?

Williams: Sure. So, I mean, you know that many enterprises struggle with application security. You know, there’s been an application security industry for like 20 years. I helped to start OWASP back in the early 2000s and I wrote the OWASP Top Ten, and organizations are still struggling with the same problems.

So, Contrast targets exactly those problems. We are kind of a radically different approach to doing application security. We’re very compatible with DevOps kinds of processes. And basically, we find vulnerabilities so you can shift left in the development and fix them. We analyze open source code, so you can make sure you’ve got safe versions of the components you’re using, and we protect applications in production. And we do it all through dynamic binary instrumentation. So, very much like a New Relic or an AppDynamics, but for security, not performance.

Shimel: Security prudent security monitoring—excellent. And Jeff, you mentioned, though I don’t know if we’ve spoken like this before, but I’m certainly aware of you for a long time within the security community. This isn’t your first rodeo. [Laughter] You were instrumental in OWASP. You know, we’ve seen application security not—it’s evolved, yes, but it’s still, at the end of the day, it’s about the application, right?

But yet, you know—look, it used to be, application security meant some kind of app firewall, which—

Williams: Yeah.

Shimel: – I’m not saying a WAF isn’t a great tool, it is. It’s changed the game in a lot of ways, I think, in what—

Williams: Not really. [Laughter] I don’t think so.

Shimel: Well, it’s made a lot of people a lot of money and it’s taken a lot of venture capital, let’s put it that way, right?

Williams: Well, that’s not my measure of success. [Laughter]

Shimel: Yeah. But has it made us safer?

Williams: Not really, no. No.

Shimel: But one can argue we’ve done a lot of things and not a lot of them have made us safer, right?

Williams: That’s right.

Shimel: You and I have both been in security for 15, 20–plus years, Jeff. And the latest buzzword is DevSecOps, and being that I’ve transitioned to DevOps five, six years ago, and I run devopsy.kinsta.cloud and I’m involved in Security Boulevard, I’m all about DevSecOps, and I’m not here to say it’s snake oil or bull or anything like that. But as we were talking about, it means a lot of different things to a lot of different people.

Williams: That’s right, that’s right.

Shimel: Why [Cross talk], what do you think it means?

Williams: Well, you know, to me, DevSecOps is a way of viewing security the way that folks viewed software development through a DevOps lens.

Let me back up. So, software had a ton of problems 15, 10, 20—I was a developer for a long time back in the early ‘90s and so on. And, you know, software development back then had tons of problems. It was late, it was very error prone, long feedback cycles, slow release times. I worked on one government program for three years, and it never was fielded. [Laughter]

Shimel: Mm-hmm.

Williams: So, that kinda thing plagued software. But, I think, DevOps has really revolutionized that, you know, basically just focusing on getting work flowing, creating short feedback loops and creating a culture of innovation of learning. Like, those things transformed the way that software is produced. I love the factory analogies and all that.

Now, if you look at security, we have exactly the same problems. Security doesn’t really deliver a tangible result. Like, you never know when you’re done. So, the work isn’t defined. That means the work isn’t flowing. You know, we have these tremendously long feedback loops. I did a bunch of work for a major financial institution. They were on a system where some apps got a one year pen test, some apps got a two year pen test, and some apps got a triannual pen test. So, every three years, they would take a look at security. It’s crazy.

And, you know, so we need to make tighter feedback loops, and security has this culture problem. It’s not a culture of innovation and learning, it’s a culture of enforcing rules and compliance and gates and guards and bottlenecks. And that all can change. If we apply the lessons of DevOps to the problem of creating security in an enterprise, we can define the work, we can create shorter feedback loops, and we can create a culture of innovation and learning. That’s really the challenge. In my opinion, that’s why security continues to struggle is, it’s just not delivering what we want it to deliver.

Shimel: Yeah. You know, and—look, truth be told, Jeff, that’s what attracted me to DevOps. I thought it was an opportunity for us to kinda reshape the playing board and maybe change the rules and finally deliver—nothing’s perfect, and I don’t think anything is, I’ve seen enough so-called silver bullets to know none of them—

Williams: Sure.

Shimel: – [Cross talk] full of crap. But I thought, at least, it shifted the game pieces in such a way that we could, it was a more even playing field, or a better situational playing field for us.

Williams: Yeah. Done right, I think DevOps can have a tremendously transformative effect on organizations building software. I’ve seen it in a bunch of large enterprises and small companies, you know, and we’re a DevOps shop here at Contrast as well. You know, we’re deploying six, seven times a day, and I have a huge amount of confidence that that makes us deliver much better software.

And so, my challenge—

Shimel: Much better software, or much—but is it also more secure? Because shouldn’t that be—I mean, that’s something I strive for, right?

Williams: Right.

Shimel: That security becomes synonymous with quality.

Williams: Yeah. That’s right, that’s exactly right.

Shimel: Is it more secure?

Williams: Absolutely, it’s more secure. But you do need some better tools. So, I think, you know, to do security in a DevOps way, you need accurate, real time feedback on the code that you’re building. If you don’t have that, then you have to have experts involved. So, there’s a fundamental relationship. If your tools are producing inaccurate results, then you have to have experts to dig in and resolve the false positives and find the false negatives and, you know, it’s a ton of human expert work.

That’s not compatible with DevOps. So, you need these accurate tools in order to give real time feedback right to developers. But that’s where instrumentation comes in. If you can get inside the code that you want to test for security or protect against attacks, that’s where all the context is. That’s where the information is. And so, using all that information, you can make really accurate decisions about whether something’s a real, exploitable vulnerability, or whether something’s a real, viable attack. And then you can give that instant feedback, you can create tight feedback loops, and you can deliver security.

And I’ve seen it work. Companies have transformed themselves from the way they used to be with a big backlog of security vulnerabilities, they’re running scans every six weeks or six months or whatever. They’re piling up vulnerabilities, they’re not really fixing anything, and that’s a very unhealthy way to be. They transformed from there into an organization where they’ve worked off the backlog and now they’re in what I call the new normal. They’re just dealing with new vulnerabilities as they come in, as part of the normal workflow. And it’s massively more cost effective, because they save all that downstream work of tracking and classifying and risk creating and all this stuff. You know, it’s super expensive and doesn’t produce anybody any value.

Shimel: Yeah. I mean, just, even from the security guy’s point of view to work in that scenario where I don’t have that technical debt, if you wanna call it that—

Williams: It is—security debt.

Shimel: Security debt. That’s a great word for it, right? Without that hanging over my head, how much easier and better is my life? And it’s so true. And the other thing, Jeff, is—honestly, until you’re at that point, I don’t think you can talk about automation and velocity and speeding up this whole thing, because when you’ve got all that dreck hanging in your background, you know, you can’t do it, right? You can’t—

Williams: Well, that’s right. Traditional security is very destructive to modern software development. If you have to involve those bottlenecks and get experts involved, I’ve seen it just wreck DevOps—you know, organizations are trying to do DevOps, but they’re hamstrung by their legacy security teams and processes and technologies. And I wish it wasn’t that way, because security has potential to be a great force for innovation.

Shimel: Yeah.

Williams: If you can give people a fantastically secure platform, they can roll out awesome applications and awesome functionality at super high speed. Do things that normally you wouldn’t think you could do, but if you have the platform, you can really make crazy things secure.

Shimel: Absolutely.

Williams: It’s just—

Shimel: I mean, and, you know, I was talking to my friends, John Willis and Damon Edward, they’ve both presented at Dozen, and the notion is, you can have it all. You can have faster applications, better, more secure applications, higher quality—all three, right? You could have two out of three ________, you could have all three doing DevOps and DevSecOps if you’re doing it right.

But here’s another thing I want to touch on, Jeff, and that is, I don’t know whether it’s shiny trinket syndrome or single-mindedness or we can’t multitask, but just because someone says DevSecOps can do, can make your life better, can do all of the things that you and I are talking about doesn’t mean that we throw everything we learned about security out the door, right?

Williams: No, no—of course not.

Shimel: Well, for too many people, they’re like, “Hey, we don’t—okay, man. You know what? Screw that AppSec stuff, we’re just shifting left,” even though shifting left is, you know, fundamentally AppSec. “We’re just shifting left and we don’t have to worry about all of these other CIA things that we learned about, right, traditionally in security.”

I don’t think anyone’s saying one necessarily replaces the other, or that it—

Williams: No, I think really it’s more about being extremely clear about the outcomes that you want to achieve with security, and then putting in place a highly tuned machine that can produce those results continuously and repeatedly over the course of a project. Shifting left is a weird term, to me.

I love the idea of doing security earlier in the process, but many people see that and say, “Oh, well, developers just do security now,” and they wash their hands of kinda the old ways of doing things. And unfortunately, that’s a recipe for disaster. I think you need to empower those developers with technologies that can let them do their coding and not introduce security vulnerabilities.

And it’s not just about shifting left, because in QA and in staging and CI/CD environments, you want to verify that everything is secure before you push to production. So, you’re really not losing that step. You need to do both, shift left and where it is now. And frankly, I think a lot of organizations should also consider shifting right and doing more protection in production. Because so many organizations that I talk to—I was just talking to a massive technology company here on the West Coast this morning—they’re really pretty blind about what’s going on at the application layer from a security perspective.

So, to me, it’s not really about shifting left, it’s actually about extending left and extending right and using a DevOps process to produce the outcomes that you really want.

Shimel: Yeah. I don’t disagree there. The reason I brought it up, though, is, you know, we could point fingers all around, but sometimes the security industry is its own worst enemy, and the cynics and the cynical within—well, we’re consuming ourselves with other stuff right now, but the cynics and the cynical folks would then say, “Oh, it’s just another buzz word, and it’s just something meant to take your eye off the ball, and we have got to hold this thing in our cold, dead hands and not let go.”

Williams: Yeah, yeah. It’s a fair point. I mean, DevSecOps is a little buzzwordy, and frankly, I’m sympathetic to the folks that say, “No, it’s just DevOps, and security is a part of it, of course.”

Shimel: Now, that’s my—so, that’s where I am.

Williams: Here’s how I think about it, though. Let me try and change your thinking about it—it is just DevOps, but there’s a view of the DevOps process that emphasizes the security pieces. It’s very much like a blueprint for your house. You know, you’ve got the elevations, then you turn the page and it’s got the plumbing plant, and then you turn another page and it’s got the electrical plant and so on.

It’s a little bit like that, for me. DevSecOps is the security view of DevOps. It just emphasizes the security aspects of the DevOps process so that you can see what’s going on and actually understand it in a little different way than if you were just viewing the whole thing all mashed together. It doesn’t really help to just smash it all together and call it all quality. So, that’s how I think about it, it’s just a view of the normal DevOps process.

Shimel: I don’t necessarily disagree. I think there’s only one DevOps, but I think—I know, I mean, so this year, at RSA, for instance, for the fifth year on the Monday of RSA week at the Moscone Center, we’re gonna be putting on DevOps Connect: DevSecOps Days. And over the course of the five years, we’ve called it DevSecOps, we’ve called it Rugged DevOps.

Williams: Yeah.

Shimel: Just don’t call us late for dinner.

Williams: [Laughter]

Shimel: And it’s kind of the security community that has driven the DevSecOps name, because they wanna make security is kinda in the middle, I guess. But—hey, whatever. If that’s what it takes to get people on board and doing things to make this more secure, so much the better.

Jeff, we started talking and I wanted to talk more about Contrast, though. Share with our audience—so, you guys are involved in AppSec, you’ve got a bunch of things going on. Any new news, anything, you know, we are coming into RSA season, everyone always has some sort of news around that. Anything you can share or talk about?

Williams: Well, I think the big thing for us this year is launching what we call run time exploit prevention, which is sort of our next generation attack detection. And the reason that it’s, I think, so compelling is because it leverages our deep experience in instrumenting applications at run time.

And so, instead of just trying to block attacks by looking at HTTP traffic and saying, “Oh, well, that’s got a SQL injection in it” or, “That’s got an XXE in it or something.” Instead, we’re instrumented deep within the code, and using that position, we can access a lot more contextual information. We can make really smart decisions about what an attack really is.

And this is interesting—we’re essentially defusing all forms of SQL injection and deserialization problems and XXE and expression language injection and so on by sandboxing powerful components inside the platforms.

So, I can give you an example. All these struts and spring vulnerabilities from over the last year and a half or so? They all involve sending untrusted data to an expression language and evaluation engine. So, what Contrast does is, we sandbox those evaluation engines to prevent dangerous stuff from happening while they’re being executed. So, you know, when you’re evaluating an expression, you don’t expect to be starting native processes and accessing files and opening socket connections and stuff like that. So, we prevent all those things from happening during expression language evaluation and restrict the program to only evaluating a normal expression.

It’s a very powerful technique for ruling out not just known vulnerabilities like in struts and spring, but we’re ruling out all forms of expression language injection, even ones that nobody’s discovered yet. So, I think that’s very exciting and puts you in a really unique position for dealing with new CVEs that are coming out every week.

Shimel: Yep. Absolutely, and that’s huge. I mean, in spite of everything and in spite of the cynicism, the pessimism, and everything else, it actually is an exciting time to be in development and security, right? We are—

Williams: I love it. [Laughter]

Shimel: Yeah. You know, we’re making progress where good things are happening in spite of, you know, every day we still hear about another breach or another, you know, incident.

Williams: Well, I’ll say this—I think it’s time that every application has the ability to detect if someone’s attacking it, and respond appropriately.

So, forever, we’ve—basically, our policy around AppSec has been, “Well, let’s build a wall around it to try to keep out the bad stuff, and then let’s scan it to see if we can find where any holes are.” And both of those approaches, I think, have sort of gotten less and less useful over the last seven or eight years, to the point where, today, they’re not really very helpful, particularly on modern applications that are built using APIs, they’re deploying containers in cloud and they move around and all sorts of things. Those approaches just don’t work any more.

So, fundamentally, building that protection into the applications itself is very compelling to me. It works at scale, it’s accurate, it’s very fast, it’s much faster than building barriers around stuff. And so, there’s just a number of advantages, and I’ve seen it transform organizations from the kind of organization we were talking about before with the huge security backlog, security debt. And they’ve, over the course of a year or a year and a half, they’ve transformed themselves across thousands of applications, to the point where they’re just dealing with the new stuff coming in. They’re in that new normal.

Shimel: Yep, absolutely. Alright, man. Hey, Jeff, we are—we’re well over our 15 minutes.

Williams: [Laughter] Awesome.

Shimel: Yeah, so, we’re gonna have to call it a break on this one. But you know what? Between now and RSA, maybe we can get you back on here, we can talk a little bit more about this. It’s a hot topic, it’s—

Williams: One quick point, if you want to try Contrast or expose yourself to IAST and RASP, you can use Contrast community edition for free. It’s fully powered, free for one app, and you can just sign up and start using it today.

Shimel: Where do you get it?

Williams: It’s at ContrastSecurity.com/ce.

Shimel: CE. Alright, excellent. Hey, Jeff Williams, CTO of Contrast Security, thanks for being our guest on this episode of DevOps Chat. Until next time, everyone, this is Alan Shimel, have a great day, for devopsy.kinsta.cloud, DevOps Chat, and Security Boulevard—take care, everyone.

— Alan Shimel

March 4, 2019
DevOps Chat: Repos and Nexus Firewall Access, with Sonatype

There are really only two repositories of any scale for software components today: the Nexus repo managed by Sonatype and the Artifactory artifact repo managed by JFrog. Up until now they were separate and apart, and working with one was independent of another.

In a big move toward keeping DevOps open and secure, the Sonatype people have released a plugin that will allow their Nexus Firewall to work with Artifactory as well as Nexus.

This means that users of both repos can now use the Nexus firewall to make sure that components or artifacts they download are in compliance with the policies they have set up. They can make sure there are no known vulnerabilities to the version users are downloading to use. This is really a big deal and kudos to Sonatype.

In this DevOps Chat we speak with Wayne Jackson, CEO of Sonatype, and Brian Fox, CTO and co-founder of Sonatype, about what this means for the DevOps community.

Transcript

Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat is breaking some big news from our friends at Sonatype. I’m really honored and happy to be joined by Sonatype Wayne Jackson and Sonatype CF – CTO, Brian Fox. I hope I didn’t mess that up, guys. Wayne, Brian, welcome.

Brian Fox: Thanks.

Jackson: Thank you, Alan. Great to be with you and great to be speaking again.

Shimel: Yeah. Well, Wayne, you and I go back just a couple years.

Jackson: [Laughs]

Shimel: Let’s not go and do a history thing. Let’s get right to the breaking news today, and that is kind of a major addition to the Sonatype – I know it’s a firewall. Do you still call it Nexus Firewall or is there a different name for it now?

Jackson: Yes, we – yeah, that’s correct.

Shimel: It is the Nexus Firewall. So before we talk about what the major addition is, let’s lay a little groundwork here. What is the Nexus Firewall? Brian, you’re the CTO, let’s give that one to you.

Fox: Alright, sure. Nexus Firewall is a set of capabilities that allow us to do analysis of components as you pull them into your supply chain through your repository and be able to match that against your policies to enforce things like architecture, quality, license, et cetera, and so specifically it’s intended to be able to stop components from coming into your supply chain when they’re known to be against your policy right up front. So you can stop developers from pulling in a component that has a known vulnerability or pulling in a component that has a incompatible license, those types of things. So that’s the role Firewall plays in the overall portfolio.

Shimel: Perfect. And, you know, let’s be clear; that – you know, a Nexus Firewall, if it’s in place the Equifax breach never happens for all intents and purposes.

Fox: Well, that might – what it doesn’t do – you know, it’s not gonna go back and take out the things you’re already input.

Shimel: You’ve already put in, you’re right.

Fox: Right. Certainly. If – you know, we still see lots of cases – I think we’ve done some of the studies recently that show organizations are still downloading the same thing that got Equifax attacked, right?

Shimel: Absolutely.

Fox: It’s the same version of Strut. So, Firewall would definitely stop that behavior, no doubt, and be able to prevent it from further propagating through your supply chain.

Shimel: And just a little shout out, Equifax is now a Nexus – a Sonatype Nexus customer, correct?

Fox: Yeah, that’s correct.

Jackson: Yes, that’s correct.

Shimel: So hope – well, at least it’ll prevent the next one, hopefully. So – but guys, so we understand what Nexus Firewall is now, and again, to put in context the importance of today’s announcement, Nexus Firewall worked when you were pulling components out of the Nexus repository up until now. Am I right or am I off base here, guys?

Jackson: No, that’s correct.

Shimel: And so the big news today is you’re expanding beyond the Nexus repository to offer protection from artifacts and code and so forth from other repositories.

Jackson: That’s right. It’s – you know, it’s an acknowledgement, and it may be the first one in this category, that just acknowledges that the DevOps world is heterogenous. You know, there are bunches of vendors and, you know, people within organizations make different decisions and we just acknowledge the need to provide universal protection.

Shimel: Absolutely. So Wayne, work with me here. It’s the Nexus repository, and with this new release out today you guys are also announcing support and protection for the Artifactory repository, correct?

Jackson: That’s correct.

Shimel: And –

Jackson: And between those two, you know, I’m not sure what the coverage is but it’s gotta be in the 90^th percentile of implemented repositories.

Shimel: I would agree with you. I think between Artifactory and Nexus it’s gotta be I would say high 90’s even, right? We’re not talking 91 or 92 percent. I think it’s probably way up there, and it’s certainly in the billions when you look at the amount of whether it be code or components or artifacts that are contained between the two of them. And Wayne, you hit on it before about the heterogenous nature of today’s DevOps world. It really is; it’s become Artifactory and Nexus as the two big ones.

But there’s another aspect to the heterogenous nature of today’s DevOps world and that is this whole notion of the software development life cycle, managing the software pipeline, the modern software factory; different companies are calling it different things but it all refers to kind of the way that software is being both written and assembled in – by, you know, modern IT departments today. Why don’t you guys expand on that a little bit.

Jackson: Yeah, I – it’s been fascinating to watch. As you know, I came from the network security world before Sonatype and had no grasp of just how much software was being written. As I’m sure you know, you know, one of the assets that we manage in the ecosystem is this thing called Maven Central, and last year we served 142 billion download requests, and so – and that’s just in the Java ecosystem and, you know, other ecosystems like NPM are just as big.

Shimel: Yeah.

Jackson: And so as we started looking at the patterns in these download requests we started to see this weird disconnect. You know, the disclosure of a vulnerability had almost no impact on usage patterns, and that led us to thinking about, you know, why that might be and how we might think about solving these problems more systematically, and it dawned on us that we had a massive supply chain problem. You know, where the producers of things didn’t have a very effective mechanism for communicating to the consumers of those things because there were just millions and millions of projects that had to be monitored. And so, you know, we started looking at the works of Edwards Deming, who was the guy that transformed Toyota from being a textile manufacturer to the world’s most efficient automobile producer, and it really wasn’t all that complicated. You know, you have fewer, better suppliers, you use the highest quality parts, maintain transparency throughout the system, and don’t pass defects downstream.

If you can do those four things, lo and behold, [laughs] producing cars becomes a lot easier. And, you know, we concluded that those exact same principles applied perfectly to software where, you know, to your point, you know, now all of a sudden these software development functions, especially in the more modern organizations, look like a software factory, and so let’s use fewer, better projects, let’s use the versions of those projects that don’t have security defects, that have the kind of license that matches our distribution model and, you know, let’s build a model where we know [laughs] what’s in the system. And if along the software factory assembly line we discover that there’s an issue, stop it there. You know, don’t pass it downstream.

So anyway, so it’s a model – you know, I’m a little bit of a car guy so it [laughs] certainly works for me, but it feels like a model that’s right.

Shimel: I agree. It absolutely does. And even before you mentioned Deming, and of course it’s obvious, I was thinking third-party suppliers just like we do see in the automobile industry. But what’s interesting is as you referenced, the sheer magnitude of the numbers here – you know, 142 billion – think about what that means. I mean it’s just an incredible, incredible amount of downloads of usage and everything else and, you know, it doesn’t take many bad apples to spoil the party for everyone, obviously. You know what’s interesting though, guys? Again, getting back to the DevOps community, the DevOps market today, Sonatype is very much – you know, who you are and what – it seems to me anyway – you know who you are, what you are, where you play and how you fit into this.

And I think that’s in contrast to – you know, we’re in a little bit of a time of upheaval in the DevOps spaces as the market matures and vendors are jostling and trying to – I think some of them might, you know, even be going through an awkward teenage phase, you know, where they’re trying to figure out who they are and what they’re gonna be when they grow up. You know, what – Wayne, you’re the CEO there – what’s the vision for Sonatype? Are you kind of comfortable in your own skin now and what is that role?

Jackson: Yeah. I think we are comfortable in our skin. I think this embrace of software supply chain management is who we are, it’s who we’re going to be, it’s sort of a unique position to take in the DevOps category, and it allows us to play very nicely with the vendors that are all a part of the assembly line, you know, whether it’s Artifactory or CloudBees or any of the other vendors. And so being able to produce information that gets translated into knowledge that, you know, automates decision-making with regard to supply chain integrity, I think is a good spot for us.

Shimel: I agree. I mean and not only is a good spot I think it’s a pivotal role to play at this – you know, as we see the continued maturation of the market and, you know, it’s all wrapped around the digital transformation and everything going on. Brian, you know, your background, you were an early chair of the Maven Project. You’ve been in this opensource, you know, world for some time, and Wayne did too coming from the Sourcefire Snort folks, but what’s your take as we see this, you know, maturation? I mean at some level it’s gotta be – I would imagine it’s gotta be encouraging to see cross – like, you know, being able to protect across different repositories, whether it be Maven and Java or Artifacts or what have you, right? It’s gotta feel like we’re making progress. What do you think?

Fox: Yeah, I think so. I mean our approach since we kind of went down this path, what, 2012 or so is to take an approach that sits above all of the tools, because we recognize from the early days when we were doing a lot of Maven training and consulting and we had the privilege I guess to go to companies and see lots of horrifying processes and all the ways in which attempts to make this better inadvertently made things worse, and we recognize that it requires a sort of across-the-life cycle approach, which means you can’t solve the problem just by adding features to, you know, the repository or the CI. And frankly, given that we were building Nexus Repo Pro back then – I mean we still are, but that was our main product back then – adding it as features on top of the Repo would’ve been the most natural thing for us to do, but we understood through all of that learning that that wasn’t going to be sufficient.

It required integration to the Repo and to the CI and to the build and to the release automation tools, et cetera, et cetera, right, to be able to most effectively nuance the process of the components that flow through that, because you may choose to respond to a policy violation differently when something is about to actually be pushed into production versus something that’s just happening in your – you know, on every commit CI build. And so for that reason, being able to integrate into all of these tools, including all of the different repos, is just natural. It’s a natural evolution of the approach we’ve been taking the whole time.

Shimel: Got it. So, I guess the next question is now that we have – you know, between the two repositories we’ve got high 90 percent of the market – how do we get 90 percent coverage with this Firewall product, right? I think we’d all sleep better. You know, what is the key, guys, to getting more people to realize this is kind of a no-brainer that they need to get done here, right? I mean what do you think is preventing us from really seeing this?

Fox: Culture. Culture and history. I think there’s a history of application security tools specifically that, you know, are prone to false-positives just by the way they worked and led – and a history of bad approaches, like I was talking about before, that tried to force bad tools onto development that ultimately led to rebellion or disuse and gear grinding, and so in some ways the security tribe I think has become a little bit afraid to engage development in a lot of organizations, right? So they very much try to work at the end of the process, try to produce lists. We know that those things tend to get ignored, that they don’t usually have a profound effect on what’s happening, and so the organizations that are really successful are the ones that, you know, can set all of that history aside and still work together in a DevSecOps type of way and, you know, look at the problem holistically and understand that, yeah, actually it makes sense. If we can stop the bad things from coming into the process to start with we don’t have to chase them out later.

The security guys don’t have to track it in the list and the Dev guys don’t have to go rework it, right? And so, you know, that’s kind of the approach that we’ve been trying to take, that all of these different constituents have an important job to play in the success of a business and it works best when [laughs] they’re all working together, not working against each other and throwing grenades over the walls.

Shimel: Absolutely.

Fox: And so really, you know, the biggest hurdle to adoption in most places just simply is that culture and the history of disdain and things like that.

Shimel: Yeah, I agree, Brian. And guys, I’m gonna tell you something. Here’s a private theory that I’ve been working on and I’m gonna be speaking about it in the months ahead. You know, we’ve worked really hard – Sonatype more than most any other vendor I can think of – to advance the cause of DevSecOps. You know, Derek and Mark on your team and myself have been putting on DevSecOps events at RSA for the last five years now, and we do it in Singapore at RSA and we go all over the world with this DevSecOps thing. And recently, in the last couple months, I’m starting to see sort of a bifurcation in how security is dealing with DevSecOps, right?

I’m seeing some companies that are embracing the Dev sides of things, and let’s call that DevSec. They’re working with developers to make the code more secure and make sure that pre deployment and everything is tested, everything is secure, and we release really tight, good quality, right? Security is synonymous with quality, and let’s call that DevSec. Then there’s another group of vendors, Brian, that are dead into what you’re talking about, right? They’re almost afraid, intimidated, or just fed up with dealing with developers, and they’re really focusing on the post deployment aspect of things here, right, and let’s call that SecOps, because they want to work more with the Ops folks, post deployment, you know, monitoring and that kind of thing.

And I’m not saying that there’s not a reason to do that or it’s not right to do that – it absolutely is – but when we start looking at it as DevSec and SecOps, we’re committing the same mistakes that we did to begin with and we’re losing that it is DevSecOps for a reason. It’s Dev and Ops and Sec all working together. We can’t say, “Oh, we’re gonna work with the Ops guys but not the Dev guys or vice versa.” It’s gotta be everyone’s in it to win it. And I –

Fox: Completely agree.

Shimel: But I’m – yeah – but I’m seeing security vendors now kind of, you know, taking sides here on this. I’ve recently done a few podcasts – and some of them are new companies that are launching or coming out of stealth and RSA, and they’re growing this distinction that they’re SecOps, not DevSecOps, or they’re DevSec, not Dev – and I think it’s a huge mistake, a huge mistake.

Fox: I think that’s largely led by the constituent. If you go and talk to the security guys, that’s what they’re gonna tell you that they want, right? It’s part of that history.

Shimel: Yeah.

Fox: You know, so if you allow yourselves to be pulled directly in the direction of what people want based on their perceived understanding of just how things work and that’s the way it’s always gonna be, that’s I think where you end up, so you have to buck that trend a little bit and say, “Guys, it doesn’t have to be this way. It can be better.” But we have to work together to do it, right, and we have to think about things a little bit differently. You know, and I have many conversations – you know, it’s happening more and more as AppSec and OPSEC is becoming more generally aware of the opensource component, you know, risk. They’re starting to come at the problem, but unfortunately they’re just trying to add more data to their existing process, and I have to remind those guys all the time that developers are picking new components all the time, they’re picking new versions of those components all the time.

They’re not only doing it because you handed them a list of vulnerable components or a list of CVEs and said, “Fix it or else,” right? So wouldn’t it be nice if you had a process and a set of tools that could support them in that behavior so they don’t come on your list later? [Laughs] Right? And a lot of times that is like a shocking realization to that tribe, right, and that’s that culture that I was talking about. It’s a big challenge.

Shimel: Agreed. And look, our work is not done, right? That’s what that means to me. We still have more work to do evangelizing DevSecOps and making sure people under – take a whole holistic aspect to it, and it goes back, Wayne, to what you were talking about in terms of the pipeline and the software, you know, automation and pipeline kind of thing, is it’s not bifurcated at the pre deployment versus post deployment juncture or junction. It – DevSecOps is about the whole thing from end to end.

Jackson: Yeah, the organizations that can think about this holistically are just bound to be more effective and more efficient and, you know, to your point about evangelism, I mean one of the things that we’re going to see, and I think we are seeing, is that the most highly-performing organizations are the ones that are getting it.

Shimel: Yeah.

Jackson: They’re the ones that are gonna be leveraging software to more effectively differentiate their business. [Laughs] And at some point, unless you want to lose, you’re gonna have to start thinking about the ways that these, you know, forward-thinking, advanced organizations are doing what they do to make themselves better every day.

Shimel: Absolutely. And you’ll have winners and losers, and look, that’s capitalism and that’s the market dynamics at play, right? You can adapt or die or not, right? I mean it’s up to you. Guys, we’ve spent a lot of time talking, you know, about this at a macro level. Brian, if you don’t mind, I’d like to get a little geeky on you and ask if you can explain to our audience at a nuts and bolts level really what’s going on with the Nexus Firewall.

It’s software, right? It’s not an appliance, per se. Where does it sit, how does it intersect, how do you set policies in it? You know what I’m saying? Let’s give our audience a little bit of a…

Fox: So our Nexus platform is kind of composed of maybe three parts. At the core is a piece of software that you run on prem or in your cloud that we call the IQ Server, and this is the thing were you define your policies, it’s the database of all of the components and which applications they’re used in, the dashboarding, the reporting; you know, all of that type of stuff occurs within the IQ Server. The IQ Server works with services that we have in our cloud to provide the real-time information around the components and the security and the licensing and all that type of stuff, right? So that’s a real-time feed, it’s not a data dump that you have to download periodically.

And then there’s all of the plugins, the plugins that go into all of the places I mentioned before; your build, your IDE, your CI, your repository, your automation tools, et cetera, right? And so what we’re talking about here is we’ve added a new plugin that plugs into JFrog Artifactory. So when a component is being proxied from an external repo, such as Maven Central, the plugin will do the analysis of the thing being requested, it will understand what it is, work with the IQ Server to understand if it’s in compliance with the policy or not, and the depending on how the policy is configured it can either allow it, it can quarantine it, or it can just outright block it, right? So that’s the same capability that we’ve had for a couple of years now inside of the Nexus repository, so it replicates that functionality for our JFrog users.

Shimel: Fantastic. Wayne, how are we going to market with this?

Jackson: I get that question asked to me a fair bit, and we have a very multifaceted go-to-market model. You know, we still have folks that are very senior out in key regions that are evangelizing, because this is still an immature market, but increasingly as the market’s maturing are starting to lead with product and product capabilities in our marketing function. So, a mixed model, but one that we think aligns with where the market is in terms of its maturity, you know, that will change over time.

Shimel: Understood. Guys, we’re almost out of time. If it’s okay I wanted to return back to the DevOps market in general. Wayne, you know, you and I kind of saw the security industry mushroom, right, from let’s say early 2000’s through even 2008, ’09, ’10, you know? I – and we now have both – and have both seen the DevOps market mushroom, you know, from 2013, ’14 to today. It’s only been four or five years. And, you know, we touched on it earlier with companies trying to kind of jostle for where they are, what they do and how they fit into this brave new world. You know, put on your visionary hat, if you will. Where’s this going? Where is it – you know, is there a logical sort of conjunction of security in the DevOps? And if so, what does that mean for the broader market? What do you think?

Jackson: I disagree with you a little bit in that – with regard to DevOps having mushroomed. I think we in the industry kind of feel like it has because now all of the sudden people are starting to use our words back at us, but I think in terms of, you know, DevSecOps being a mainstream thing that’s just a part of how people work is still a bit away, and I think, you know, the work that you’re doing, I think the work that we’re doing and other vendors in this space is still enormously critical because even organizations that aspire to DevSecOps still need help. It’s not an easy thing to embrace and implement, as you know, and so there’s still some work to do, which I think is cool.

Shimel: Yeah. Well, it keeps me going every day and gets me up. And you’re right, you know, we tend to forget that we live in a bubble. When you’re a hammer, everything looks like a nail, right?

Jackson: [Laughs] Right.

Shimel: When you’re talking DevSecOps all the time people tend not to look at you and say, “What are you talking about?” So, you know, we kind of breathe our own exhaust, if you will. But there is, there’s a lot of work to be done, even – forget DevSecOps – even in the basic DevOps level, right? When you – a lot of companies have dabbled in DevOps but how many are truly end-to-end DevOps, right, and that number I’m gonna guess is well – is below 20 percent, probably closer to 10 percent.

Jackson: I think you’re right, I think you’re right.

Shimel: Yep. So our work is still in front of us. But hey, you know what? It wouldn’t be fun if it wasn’t, right? I mean that’s what keeps us –

Jackson: [Laughs]

Shimel: Anyway, guys, when is this new plugin for Nexus Firewall available?

Jackson: More or less now.

Shimel: Okay.

Jackson: I think the official release date is March 1, but yeah, happy to show it to anyone who’s curious to see and very proud of the technology.

Shimel: Absolutely. And they can get more information at Sonatype.com?

Jackson: That’s right.

Shimel: Fantastic. Wayne Jackson, Brian Fox, CEO and CTO, cofounder of Sonatype, respectively. Thanks for being our guests on this episode of DevOps Chat.

Wayne Jackson: Thank you. It’s been our pleasure.

Fox: Thanks for having us.

Shimel: Always a pleasure. Always a great time, guys. Okay, this is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. Have a great day, everyone.

[End of Audio]

— Alan Shimel

February 28, 2019
DevOps Chat: JFrog Acquires Shippable

The big news in DevOps today was the acquisition of Shippable by JFrog. This adds a CI/CD solution to the JFrog Enterprise+ platform and further expands JFrog’s end-to-end DevOps offering beyond Artifactory and more.

In this DevOps Chat, we speak with Shippable CEO Avi Cavale, JFrog CEO Shlomi Ben Haim and JFrog VP of Marketing Ayally Goldschmidt about the thinking behind this acquisition and JFrog’s plans going forward.

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

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, you’re listening to another DevOps Chat. Today’s DevOps Chat has some breaking news. It was just announced this morning—JFrog has acquired or merged with Shippable in a rather, you know, this is big news within the DevOps world, and we’re very, very happy to be joined by the CEOs of both Shippable and JFrog. From Shippable, we have Avi Cavale, and from JFrog, of course, our friend, Shlomi Ben Haim. And joining us from JFrog is Ayalla Goldschmidt, who really runs marketing at JFrog. I’m not sure of your exact title, Yes, Ayalla?

Ayalla Goldschmidt: VP of Marketing, thank you, Alan.

Shimel: VP of Marketing—thank you for joining us. So, first of all, to all three of you, congratulations, Mazel Tov as they say in Seattle. [Laughter]

Goldschmidt: Thank you, thank you.

Shlomi Ben Haim: [Laughter] Thank you, Alan.

Shimel: Thank you. And so, you know, Avi, let’s turn it over to you first. I think a lot of our audience is familiar with JFrog, and most of our audience have heard of Shippable, but let’s just lay that right out there. What’s Shippable about?

Avi Cavale: Shippable is about a modern CI and CD platform. So, our focus is to streamline the delivery—packaging and delivery of software, and that’s kind of where we are focused on.

Shimel: Fantastic. So, Shlomi, I think I already know the answer, but I’m gonna ask you—why Shippable for JFrog?

Ben Haim: That’s a great opening question. Actually, Alan, you know JFrog very well. You know that everything starts with the culture, and when we met Avi and the team, it looked like we’d found the brother Frogs in a different company. So, for us, it was just to make sure that the technology and the strategy are aligned. And when we looked at the technology and the next generation of CI/CD that was built by the Shippable team with Avi’s leadership, it was a no-brainer for us.

Shimel: Absolutely. But the other thing I think we should mention is, you know, JFrog, many people know JFrog from Artifactory, maybe Xray, you know, point solutions that we can call up. Artifactory is a whole platform in and of itself.

But, really, the big move for JFrog—and if I’m wrong, correct me; Ayalla, you’re the Marketing person—the big move for JFrog was, you know, this JFrog enterprise platform. And, to me, if you’re gonna have an enterprise platform in the DevOps space, you need that CI/CD pipeline kinda delivery capability.

So, to me, you know, this really kinda helps fulfill that vision of the JFrog platform. Yeah, no, wrong?

Goldschmidt: Yeah, that is exactly right, Alan. That’s the vision that we have for it. Obviously, we’ll be doing a lot of work here in the coming weeks to clarify the roadmap and the timeline, but you hit the nail on the head. That’s the value that we’re seeing for our customers and what they’re looking to, what they’re asking us for as far as, you know, we love JFrog, we have very happy customers, they love what we do, and they’re looking to take it to the next level.

Shimel: Excellent. So, let me ask my next question to Avi and Shlomi, and that is, you know, I guess it’s part of the maturation of the DevOps market where all—you know, there are now, everybody wants to offer the whole enchilada. Do you know what I mean?

Ben Haim: [Laughter]

Shimel: People aren’t content any more just offering a piece of it, we wanna offer it all, that whole SDLC, we’re gonna help you throughout that life cycle. It seems everyone is pointing towards that, and the money—look, JFrog, it’s no secret, raised $165 million. Some of your competitors have raised also eight figures. That’s where the smart money’s going, towards companies that are building out this end-to-end DevOps framework.

Avi, is that what you saw at Shippable, and is that what attracted you guys to want to do this deal with JFrog?

Cavale: Yeah, I think what we are seeing is that there is one thing which is very critical for customers. It’s like—yes, they want the whole enchilada as a single platform, but at the same point in time, they also want a platform that is open, and they want to make sure that they can plug in the tools that they like in certain places.

So, of course, they want to see the native capability end to end, but extensibility is also super important. And so, what we kind of saw with what JFrog was doing and what we were doing also was that we were being open to everything. I mean, yes, we want to have a standard of how we think about an end to end platform, but we want to be open and make sure we embrace all the practices that developers want to do and extend the platform to DevOps capabilities.

Shimel: Absolutely. So, Shlomi, Avi makes a very good point here, and that also goes to the heart of JFrog. One of the things about JFrog is that they play nice with everyone, basically, right? You could pick whatever CI/CD platform you wanna work with or whatever—you know, whether it’s Puppet or Chef or the Red Hat software, you know, JFrog works with everyone, so to speak.

But now, you have an in-house CI/CD solution, so how do you balance that in your go to market?

Ben Haim: That’s a great question, Alan. I think that what we’ve started to see in the market for more than 12 months now is that DevOps is maturing and the organization and enterprises are looking to get an end to end solution, yet the driving force of DevOps production is still in the hands of the developers, which, obviously, would love to see the freedom of choice and the best of breed options kind of open to them.

So, you are right. Our universal approach is something that always led us. We always provided our users with the power of choosing their tools pack, and it will still be the case.

However, on the JFrog platform, what we call the enterprise class, we want to make sure that we take artifacts seriously, from the moment you build it from code all the way to production. And, together with Shippable automation power, together with the integration and the visibility that technology like Shippable can provide to the platform, I think we will be able to combine the two, to allow a better universal approach. So, you can still use your Jenkins, your CircleCI, your other DevOps tool sets. But you will also have a JFrog end to end solution that takes you all the way from code to production.

Shimel: Excellent. So, Avi, you know, how do you—I’ll reverse, mirror that question back to you, right? How do you see the Shippable team, the Shippable product fitting into that JFrog Enterprise Plus, you know, the Artifactory platform, all of the different tools that JFrog and services that JFrog is putting together—how do you make sure you fit in there?

Cavale: So, as Shlomi mentioned, right, what is happening is—so, the artifact is something that is immutable, and that’s something that you build and you want to kind of take it through your entire value chain of how you deliver software to your end customers or end devices or whatever they might be.

The issue is that, if you don’t have the pipes to kind of control that in a high fidelity fashion, you lose a lot of information as you go from stage to stage. Because you’re leaving it up to the customer to make sure all the data is being persisted and you’re keeping all the hooks so that eventually what you’re really trying to do is, you want to be able to go to something that’s running on the end device and be able to track, if there are problems, what are all the pieces that went into actually building that piece of software that is running there?

So, losing that ability to connect that entire life cycle, all the way from code to the point where it’s running on a device is a very critical piece of DevOps. And what we see is, that kind of, now, our marriage to the whole Artifactory plus Xray and plus distribution, all of those pieces now can be connected through a common pipeline and we’re making sure that we have high fidelity information exchange as things move through this work flow end to end. And I think that’s kind of the critical thing that we are adding to the product.

Shimel: Excellent. Ayalla, a question for you—you look at, all of a sudden, you’re embarrassed by the riches of JFrog in terms of their product, right, in terms of the product that you have to work with, the products that you can bring to market. But at the same time, at some level, it’s a double-edged sword from a marketing perspective, right? You have so much now, too, that you need to market, that you need—how do you make sort of a holistic message for market that includes all of these pieces and how they fit together and how, if you don’t want to use all the pieces, you don’t have to, either?

Goldschmidt: You know what, I feel like the luckiest marketing person on the planet. And, you know, Shlomi promised me when I joined this company a little over a year ago that there will be no shortage of news, and he has delivered.

Shimel: [Laughter]

Goldschmidt: So, since I’ve joined, the acquisitions, our Series D announcement, and of course, all of the new technologies that we’ve supported along the way, and the most recent exciting edition of support for Go and Go Center, we love all of these audiences and we do actually put in a big effort in tailoring our message to make sure that we’re communicating with a developer first mindset, and that seems to be working for us.

So, you know, until today at JFrog, everything we’ve built has been through an inbound marketing funnel with an inside sales team. We haven’t had field people knocking on doors, and that seems to be working great for us, and now we’re ready to take it to the next level. But we’ll always remain developer first.

Shimel: Excellent. Let me—Avi, let me ask you some sort of typical M&A kind of questions. So, is your whole team staying on as part of this acquisition?

Cavale: Absolutely, and we’re all joining the JFrog family, and so there is really no change to the business and how we are running it. And I usually tell my team that I have a new boss, that’s all—nothing else is changing, and we’re gonna keep marching towards the vision, and all we have is an opportunity to broaden that vision that JFrog brings to the table and we are part of a much bigger family than what we were before.

Shimel: Excellent. And so, Avi, what do you see particularly as your role going forward, here?

Cavale: Sorry, was that for me?

Shimel: Yes, specifically you—what’s your role going forward? Is it just heading up Shippable? I mean, I’ve been in your role, to tell you the truth. I’ve had my company acquired more than once. And, while you still want to maintain your team and run the team, you also need to integrate now, right? You’re part of an executive team at JFrog that has—I will tell you, I think one of the best cultures in the DevOps world or in the tech world, period.

You know, how do you see yourself? How do you see this changing your role? It’s more than just having a new boss.

Cavale: I think the way—I’m actually in Israel right now, and we have already started collaborating. So, one of the things that I actually see is that the team is like, it’s all about brainstorming, quick integration. So, my role is to make sure that I’m delivering the products that JFrog’s customers love as well as most importantly the trust that it actually runs the way it needs to be running. And we’ve focused on the CI/CD aspect of it; nothing is changing from that perspective.

But what I have now is more brains who are kind of helping me think through what we need to actually do so that we are focused on the enterprise and driving towards that, so that’s kind of how I see myself, as part of the team.

Shimel: Excellent. So, Shlomi, let me ask you, now—what’s next? What worlds are left to conquer? What pieces of the puzzle are missing? What’s next?

Ben Haim: You know, Alan, I’m sitting here and listening to Ayalla and Avi and this is great. And from people from outside JFrog, they might think that JFrog is trying to complete the pipeline with all kinds of pieces.

But the one great feedback that I’m getting from the community is that there is no question mark. People understand what are we doing, it all makes sense. Every tier, every brick that we put on the DevOps wall sounds like the right, next logical step.

But we are the binaries people, and we will stay the binaries people. We will just make sure that this pipe is completed, and when we speak about the liquid software vision, when we speak about continuous update and solving the pain for the DevOps world, we are taking it seriously, and, as you see, we are super determined to complete our mission.

What next? We have to stay focused, we have to be a great solution to our customers and users as a community. We are very active in the community, providing them with more tools and more capabilities. It is now our responsibility to make sure that Shippable is fully integrated and the user experience is smooth and fun to use, and as Ayalla mentioned, thinking of the developer first and not the full platform story, but the user experience and the fun and simple-to-use solution.

Shimel: Excellent, excellent. Alright. Guys, we’re about out of time, I think. We’re probably over time. But again, Avi, congratulations. Welcome to the JFrog family.

Cavale: Thank you.

Shimel: It’s an amazing culture, and I’m sure you probably already know that, but you’ll continue to find out. Shlomi, my friend, congratulations to you. Keep up the great work. I can’t wait to see you.

Ben Haim: Alan, thank you.

Shimel: Thank you.

Ben Haim: Thank you so much, partner. Thank you so much.

Shimel: Alright. And Ayalla, always a pleasure.

Goldschmidt: [Cross talk]

Shimel: You, my friend, have work ahead of you now. [Laughter]

Goldschmidt: [Laughter] Yes, I do. The work is just beginning.

Shimel: Good for you.

Goldschmidt: Thanks for having us on.

Shimel: Alright. So, big news today—JFrog acquires Shippable, and another brick in the wall, as Shlomi mentioned. I tend to think of it as more of a Pink Floyd song than any political thing, but it certainly is continuing this DevOps maturation.

Guys, congratulations. We’ll see you all soon. And for now, that’s a wrap on this DevOps Chat. This is Alan Shimel for devopsy.kinsta.cloud. Have a great day, everyone.

— Alan Shimel

February 21, 2019
DevOps Chat: Mainframe DevOps Update With Compuware’s Chris O’Malley

Christopher O’Malley is one of the leading voices in the DevOps for mainframe community. He is relentless in advocating how the mainframe platform can not only exist but also thrive in today’s Agile/DevOps environments. His evangelism keeps his company, Compuware, front and center in the mainframe DevOps discussion and it really lifts the entire market.

In this DevOps Chat, we catch up with Chris to talk about the latest release of Topaz, trends in the mainframe market and what we can expect in the near term.

Chris is always a great interview with lots to say and this interview is right on point. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. This DevOps Chat features a return of our friend, Chris O’Malley, CEO of Compuware. Chris, happy 2019 and welcome back to DevOps Chat.

Chris O’Malley: Thank you and glad to be here, Alan.

Shimel: Absolutely. You know, Chris, it is. It’s 2019; DevOps continues to mature. And I think one of the trends that we’ve seen, certainly over the last year and I expect it to even accelerate this year, is changes are coming to the DevOps and mainframe market. Right? Mainframes aren’t going anywhere; in fact, shops that are using mainframes, I think their footprints are increasing, rather than decreasing.

And, from what we see in our readers and in talking to them, is that they are eagerly anticipating new developments, new functionality, that their mainframe software will offer, that will allow them to leverage DevOps types of foundations, DevOps types of functionality. And, I mean, DevOps and Agile and, really, code word: continuous delivery, all of these new ways that we’re defining the modern software factory, if you will. You’re in the driver’s seat for it, right, Chris? I mean, Compuware is kinda leading this charge. What do you see – you know, put on your analyst glasses here. What do you see in the market?

O’Malley: Well, first, just confirming what you said about the mainframe, is that the z14 has been awakening, I think, for customers and analysts, in terms of its success, so the z14 is the most successful mainframe model in over a decade. It’s had five consecutive quarters of year-over-year growth, which probably hasn’t happened in maybe forever. And, as you said, the reason that’s happening is the mainframe is still unmatched in terms of its reliability, its performance, its security, its transactional efficiency. And all of those things, all those virtues, are incredibly important in a digital age, where you try to basically create a customer experience through software. So the mainframe, as you say, it’s not just doing well; it’s actually doing better than historically because of the digital age.

Shimel: Mm-hmm.

O’Malley: So, just giving my disposition on the mainframe and the mainframe’s role within DevOps, I think, if you kinda zoom out a little bit to make sense of what’s happening to the mainframe, you gotta start first with the fact that all of these companies that use mainframe are of a mindset that “We’ve gotta be customer-centric. We’ve gotta serve our customers, whether they’re individuals, if they’re federal agencies, whether they’re citizens or it’s business-to-business.” But, for 100 years and for 100 years from today, companies that are the most customer-centric, obsessed with customers, do the best.

And, when you look at kinda this modern age, to do well from a customer-centric perspective, you’ve gotta create awesome digital experiences. And that’s done by writing software. So companies – you know, and Amazon has taken the lead in a lot of these kinda more newer-age companies. They’re incredibly good at taking ideas that matter to customers – and, again, it’s usually through digital means, increasingly – rapidly turning those into deliverables that make a difference. And, whether it’s centered on creating these awesome experiences and when they kinda look at the measures of what they’ve gotta do better to turn those ideas into deliverables, they’ve gotta be really good at velocity, how fast they do those things. They can’t do it in ways that compromise quality, so quality has gotta be something that’s constantly getting better and they’ve gotta become more efficient.

I mean, in the manufacturing space, they talk a lot about getting rid of non-value-added efforts and thinking about retooling things that are a cause for technical debt, that encumber your ability to increase velocity and improve quality, so you’ve gotta fixate on the efficiency side of it. So these three metrics are emerging as foundational to improving things like customer sat and improving financial performance.

So, when you start now getting closer to large enterprise IT, you’ve got a mainframe, these ideas that matter to customers don’t neatly fall either on the mainframe, in terms of the coding work that’s gotta be done or the cloud or some other platform, almost always, these ideas span these platforms. So there’s a necessity to improve velocity, quality, and efficiency across the entire enterprise.

So, you know, the mainframe, historically, has been this kind of silo-ed organization that had its own culture, its own set of processes, its own set of tooling. And, as you said, the mainframe’s not going away for all the right reasons. In terms of creating these awesome experiences, reliability matters. Performance matters. Security matters. How efficiently you do that, from a cost standpoint, matters. But you gotta draw the mainframe to be a like system and make it different only in syntax from these other platforms.

So there’s a strong move within these large enterprise ITs to break down this silo, get rid of a house divided against itself, bring the mainframe into a culture that’s centered on innovation, not on maintenance, bring it from waterfall to Agile, to bring it to a tooling set that’s familiar to non-mainframe platforms, the products like Jenkins and SonarSource and SonarLint or Paris. All these type tools that are used aggressively to improve velocity, quality, efficiencies on these other platforms, bring these to bear on the mainframe.

So that’s what’s causing, I think, the mainframe to be in this kind of disrupted state of trying to get the culture to move, getting people to think and behave differently, to embrace this kind of new order of how work is done, Agile techniques specifically, and to get away from – you know, the mainframe has always been selectively automated in incredible ways. I mean, the transaction volumes it can support are unmatched within the marketplace, but it’s selective automation, not intrinsic automation, which is a big part of what DevOps tries to push. And getting rid of non-value-added work on the mainframe and getting to the point that the value-added work can be done, again, faster, greater-quality, greater-efficiency.

So that dynamic is now gone from kind of innovators and early adopters within the mainframe market, you’re now getting into more of the early majority, so you’re seeing it more prod-based, in terms of people looking at the mainframe as that “We’ve gotta make this like any other platform.” And I think the success of the z14 makes sense, why it’s doing so well. Not just better than the z13, but better than previous releases over in the last 10, 20 years, so it’s exciting times in the mainframe. And I think its success is gonna be something you see emerging over the next ten years.

You’ll see fits and starts and, obviously, problems, but one of the things that’s making me so excited – you’re seeing successes in the market that are outrageous. We’ve got customers at Compuware that are increasing their development productivity by a factor of 4, I mean, a 400-percent increase in productivity, so they’re getting 4 times the number of story points completed within a release cycle. They’re taking testing time from weeks to minutes and with better quality. And, when that is understood by customers, you know, if you can go from weeks to minutes, that’s a lot of non-value-added work that you’re doing, right? That’s like burning money in the parking lot because a customer’s not gonna give you more money to do the same or less quality in what you can do in minutes, as opposed to somebody that’s a laggard doing it in two weeks.

Shimel: Absolutely.

O’Malley: So you’re seeing these amazing success stories. Again, it’s not just our tools; it’s _____ –

Shimel: No, no, it’s important – Chris, it’s that 10X, right? Everyone’s looking for that 10X. And we’re starting – you know, 4X is great; 5X is better. We’re getting those – we’re hearing success stories, the 10X success stories, with mainframe. And it goes back to something else you said, that, instead of people saying, “Oh, I’m winding down my mainframe or I’m migrating mainframe,” no, I’m looking at a ten-year roadmap on mainframes. It’s not – a couple years ago, there was this – I don’t know – fake media, fake news, about “Yeah, well, it’s here now, but we gotta kinda wind down.” What you’re saying about the z14 is exactly right; it’s bigger than anything that’s come before it, in essence, right?

Here’s another thing, though, Chris, and I’m interested in your take: kudos to the mainframe software market and vendors, who are recognizing – not all of ’em, not all of ’em, but the ones who are, the enlightened ones, who are recognizing this and are capitalizing on it by bringing the tools the market wants to bear. It’s more than just the hardware, right? The hardware’s phenomenal – I’m not gonna deny that; IBM has done amazing with the z14 – but the software vendors, including Compuware, right – take a bow – have really delivered. You guys have a new release coming out or just came out, is that right?

O’Malley: Right. It’s the 17th consecutive quarter that we’ve come out with new capabilities, upgrades to our classic offerings and integration with awesome and preferred DevOps tools, so, yeah, we’re very excited about this newest release.

Shimel: So talk to me. Give me the three biggest things that get you excited on this release, Chris.

O’Malley: So, each quarter, we’re turning the crank in terms of trying to nail the jobs that are changing, right? As I explained earlier, when you’re going from waterfall to Agile and from selectively automated to intrinsically automated, you’re trying to go from maintenance to innovation, the jobs that people have to do change radically. And they change radically in ways that are difficult to achieve. I mean, when you’re working on the mainframe, you’re working with large code bases, large in terms of the quantity of those code bases and also the size of any one of them.

So these techniques, at a high level, just seem obvious, but the practical things that need to be done from an innovation standpoint to help people to nail these things, it takes a lot of innovation. I mean, we’ve had to do a lot of work to get to the point where you’re seeing orders-of-magnitude improvement in the way people develop, the way people test, so this latest release is just another chapter in that story.

So we came out with Topaz team profiles, so that’s a good example of a capability that allows those that are working on systems to basically be able to store their configurations, the inputs and outputs of these applications, the test artifacts that are used, and build those artifacts and configurations in ways that can be shared broadly within teams or across the organization. That’s important for a couple things – one is the work to do that, you wanna do it once and then do it once for every one ’cause, in the DevOps mindset of continuous improvement, you wanna get rid of things that aren’t value-added, things that customers won’t pay for.

So, in creating this capability, we allow now, as teams get spun up, right, you get a team that’s gonna work on a two-week sprint, you want them, out of the gate, to be productive. So being able to share profiles day one, with people that may have never worked on these systems before, is crucial so that you’re productive in the first minute of the first day.

You also have situations where you’ve got, instead of technical debt issues, maybe a team, a large team, that you wanna go after certain work. It’s gonna help to improve the future throughput of the incremental efforts you have, from a development perspective, in the future. And you’re gonna bring large groups of people to work on something and that may be an outsourcer that you’re engaging; it may be new college recruits that you’re engaging. But you, again, want those people to be as productive as possible, as quickly, so, if you’ve got an experienced person on your staff that can create all those configurations and then share that broadly, again, you’re gonna lessen the ramp-up time for them to do their effective work.

So, again this is another example of us thinking about the mainframe going from waterfall to Agile, at scale, and having a scenario where it’s not just people that have been on your staff for 30 years, working on the same subsystems of your applications, every day for their entire career. Now, ’cause ideas are paramount and where people work has more to do not with what they know but what the company wants to do in better servicing their customers, so there’s more of a randomness to the work and a changing nature to the work, and what you work on is fluid. So we’re really thinking deeply about the implications of that and, for profiles within Topaz, that’s a major step in the direction of getting a different way of working within IT.

The second thing that we’ve released is another Jenkins plug-in. Jenkins is a central part of CI/CD pipelines, in terms of the automation side of it, and we’re constantly thinking about “What are the things or plug-ins that need to be created to make the mainframe equal to any other platform in all ways, other than syntax?” So JCL, Job Control Language, is a very important part of how programs are run within the mainframe. Creating a plug-in to help bring it into the CI/CD pipeline efforts and the automations efforts was a crucial thing that needed to be done, so it’s a contribution, from an artifacts standpoint, that, again, takes another step for our customers.

And then, lastly, is in the area of testing. Compuware is the leader, if not exclusive, provider of unit and functional testing as a combined offering. It’s a necessary part of the job that people have to do within Agile, with this concept of shifting left. The developers aren’t just coding; they’re coding and testing, both in terms of bugs and performance, and becoming much more extended in terms of their role. And so their accountability and responsibility is bigger.

So they need tools, like unit and functional testing tools, to participate within a two-week sprint process so that their deliverable, at the end of that cycle, is one that’s close to bug-free as possible and not putting future work into the system where it comes back as some quality issue 6 months later, 12 months later, when it runs into production, or, you know, as usability concern. So these three things are another turn of the crank, if you will, and Compuware’s offered to help customers nail these jobs, these new jobs that are created within kind of Agile work environments and DevOps work environments.

Shimel: Excellent. Anything else on the new release before I go off on another direction?

O’Malley: No, it’s just we’re very excited ’cause we released a technology called “zAdviser,” six months or so ago, which is a method of collecting what business KPIs for customers and then looking at, actually, stats relative to our products, so we can see kind of the behavior of developers. And we’re working with companies collaboratively to treat their people as they should, like high-performance athletes rather than slaves in a Roman ship galley. You can say, “Work harder. Work faster.” Well, you’ve gotta be constructive in helping to share best practices and methods that have a positive effect in things like velocity, quality, and efficiency.

So, with every release, we’re seeing a significant increase in this KPI performance, so, as we’re talking about earlier, the mainframe is certainly on a march to become a first-class citizen within the digital age, within these enterprise customers, but the more _____ –

[crosstalk]

Shimel: I’m sorry; go ahead, Chris. Go ahead.

O’Malley: Go ahead.

Shimel: Well, no, I was gonna say, you know what I find interesting is, yeah, we’re talking about the mainframe machines, but so much of your focus is on the people, on the developers, on the team, because, at the end of the day, that’s the gold. Right? That’s the almost irreplaceable asset, are the people and the developers and the IT teams that are working on these mainframes. And it’s about empowering them. Right? So I think that it’s the right place to put the focus.

O’Malley: Yeah, people –

Shimel: Yeah, I –

O’Malley: Just to restate the obvious here, but people matter most. When you think about the mainframe in the context of Agile and DevOps, asking people to change their role, though they’ve been around for 30 years, 40 years, dramatically – I mean, the day in the life in Agile and DevOps is vastly different than the day in the life of status quo. And it’s important that, as leaders, you’re promoting the appropriate culture and getting people to understand why they need to change, important that you’re giving ’em the necessary education, teaching them how to be effective in Agile sprints. I mean, that’s a different way of working. I mean, it’s not that you’re working 24 hours a day, but you’re definitely working in a more intense way. And then products matter then. The tools have gotta be enablers, not things that fight against your efforts to adopt this new culture and Agile nature.

And, you know, I really try to express to IT leaders, “You gotta think about these things ’cause – ” you know, we use this example, the Gallup survey. Gallup survey have been doing this thing for 20, 30 years of employee engagement in large enterprises, and what’s most interesting about it is, over 20, 30 years, the employee engagement statistics haven’t really changed. And it’s disturbing when you actually hear about them. Two-thirds of employees in most large enterprises are not engaged, half of them are kinda, “It’s a job; I don’t care that much,” and 16, 17 percent are actively disengaged – they try to sabotage the efforts of the companies.

So one of the biggest problems is engagement and employee engagement, and so I try to get people to understand – people matter hugely. And you’ve gotta give ’em the culture necessary to thrive in this more competitive age, you’ve gotta give ’em direction in terms of the process, the way that work is done, but you gotta give ’em the tools. You know, asking ’em to use mainframe tools out of a NASA movie from 1965 and thinking that something’s gonna happen is incredibly naive, so –

Shimel: Absolutely. You’re not landing people on the dark side of the moon with that. Chris, we’ve got a few minutes left. I wanted to touch on another subject – we didn’t really kind of pre-talk about it, but I’m sure you’ve got some great views on it – I was out in Seattle last month for KubeCon, you know, Kubernetes, cloud-native. It’s a funny question to ask the mainframe guy the cloud-native question, but, certainly, containers are no strangers to mainframes.

O’Malley: I mean, they’ve been on the mainframe for –

Shimel: 20 years, maybe more, right? 25. So anything specific to Kubernetes in the Topaz or Compuware kinda roadmap that you can discuss right now? Or what effect do you see on your world?

O’Malley: Yeah, so, when you think about kind of the flow of work in large-enterprise IT and what developers are fixated on, I mean, part of it is innovation and functionality that they’re trying to build, which is most important. I mean, that’s the value-added efforts of developers that make a difference in the eyes of the customer. And you wanna do that as quickly as you can, with the greatest degree of quality.

But the other things you gotta think about are things like quality itself. I mean, if you get anything that you release that’s got bugs in the system, how rapidly you can respond to it. That’s always part of the work that’s being done and I don’t know of any organization that doesn’t have some degree of bugs. And bugs may be software written improperly – and, again, our tools are helping to fix that – or usability issues, integration into other systems.

There’s also the work of compliance and security that you gotta do, but this last thing is this thing, technical debt, right? That any code base that’s had any life to it, has meandered through the efforts to serve customers, it’s something that grows over time. And it has nothing to do with mainframe; it happens everywhere. You know, the cloud – you know, Amazon’s got debt. And you gotta deal with that technical debt, so, as you’re dealing with technical debt, the smart approach is to start using more of these modern techniques. SOA was kind of a philosophical approach to breaking down these larger systems into smaller subsystems. When I think about API enabling, REST Y enabling these kind of smaller chunks, but you also wanna think about containerizing, using these as a form of containers, Docker being the method of creating the container, Kubernetes of being the way of managing these.

So we do see this playing an increasing role _____, as people start really looking at affecting technical debt ’cause that gives you the biggest bang for the buck. I mean, you certainly wanna do it with any new functionality you’re doing, but you’ve got some huge numbers of lines of code that you’ve developed over four years that works awesome. I mean, it’s really good working code, but making it more manageable and getting rid of that technical debt. Part of that equation is RESTful APIs; it’s containerizing it and managing it more in a cloud-like fashion. So, yeah, you’ll see us enabling those tools.

Our approach has always been to go to the edge of the mainframe and then we stop. We take care of what we know best and getting rid of these esoteric differences, but then, when we go off the edge of the mainframe, we work with all these other vendors. We allow SonarLint and SonarQube to do its work on COBOL, as akin to what it does with Java or C. Parasoft is a testing framework, allowing our products to work within that orchestration.

So there’s all these tools that work in kind of the DevOps world that are preferred and we’re enabling them, so you should think of us doing things in support of Docker and Kubernetes over the long term. But, yeah, it’s an important part of making mainframe IP one that the throughput can constantly be improved and those techniques obviously help enormously.

Shimel: Absolutely. Chris, I’m sorry to get you going ’cause it doesn’t take much when we start talking mainframes and DevOps, but we’re way over time and I need to wrap up. Hey, we’ll have you on, certainly, next quarter for the – what will it be? – the 45th time?

O’Malley: [Laughs] We’ll be doing this and it’ll be our 1,000th. You and I will be in wheelchairs, talking about it.

Shimel: By then, you should be down in Florida with me, but, anyway, Chris, it’s a pleasure having you on. Continued success with Topaz and Compuware. And we’ll catch up with you soon?

O’Malley: Always a pleasure and anytime I can help.

Shimel: All right.

O’Malley: And thank you for the hard work that you do.

Shimel: Thank you.

O’Malley: _____ important _____ –

Shimel: All righty. Chris O’Malley, CEO, visionary, leader at Compuware, on DevOps Chat with me today. This is Alan Shimel and you’ve just listened to another chat.

— Alan Shimel

February 21, 2019
DevOps Chat: App Modernization and Service Virtualization with IBM’s Matt Tarnawsky

While everyone wants to focus on building a new app, the fact is there are many, many apps already out there. They need to be maintained, updated and modernized. How do you upgrade these legacy apps to new infrastructure, frameworks, languages and more? App modernization is a thing.

In this DevOps Chat we speak with Matt Tarnawsky of IBM about app modernization and service virtualization, testing and more.

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

Transcript

Alan Shimel: Hey everyone. Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. In this episode of DevOps Chat we’re going to spend time talking about app modernization, testing, service virtualization. We will see what else kind of gets dragged in within our time frame.

Our guest, you know, who’s going to serve as the expert today, Matt Tarnawsky. Matt, hopefully I didn’t mess that up too bad. Matt is with IBM. And Matt, welcome to DevOps Chat.

Matt Tarnawsky: Thank you, Alan. Good to be here.

Shimel: Absolutely. Pleasure to have you here. So Matt, first of all, I did not mangle your name too badly, I hope.

Tarnawsky: No, you got it pretty good.

Shimel: Fantastic. So Matt, following our tradition here on DevOps Chat, we like our guests to introduce themselves. So why don’t you tell us a little bit about your current role at IBM and also a little bit about your own personal journey that led you to be here today.

Tarnawsky: Sure thing. So I am the product manager for IBM’s Rational Test Workbench and Rational Test Virtualization Server, specializing in API testing and service specialization. In terms of how I got here, I have had an interesting journey, starting off with working with a lot of the circuit boards and SPGAs, working with those and then testing those as well.

I ended up migrating across to working with a small company called Green Hat Software building, AGI testing and service specialization tools. We were acquired by IBM several years ago and I’ve been enjoying the journey ever since.

Shimel: Good for you. That’s a great story met. And you know, it’s fairly – it’s more usual than unusual in the IT space when you see someone – when we look at the arc of our careers, five years from now who knows what we will be working on. It may not even exist or we even know about it today. So it’s kind of right par for the course.

So Matt, as I mentioned earlier, I wanted to talk a little bit about app modernization. In my mind, anyway, it’s a loaded – that phrase is a loaded phrase. We hear it bandied out about a lot but when you talk to people – to some people they are talking about, “Well, I am modernizing my existing app. So I’m taking my legacy applications and modernizing them for new infrastructures, new delivery methods, new imports, what have you.” So really about modernizing your existing legacy applications.

To other people, though, it’s more about modernizing the way you develop, deploy, and manage applications. So modern – application modernization. Of course, no matter how we are talking about it, testing plays a vital role in this. So why don’t we first do a little level set. You know, Matt, what you – when you hear app modernization, what does it mean to you?

Tarnawsky: So to me, it encompasses a lot of things you mentioned _____ _____ _____ _____ people talk about is, how to do I _____ _____ my app to new markets, new interfaces. That can be things like mobile. It can be things like presenting apps _____ _____ _____. And that often does require _____ _____ _____ _____ their interfaces to actually bring them into the _____ away from our systems that they may have had in the past.

But often, it also means they want to look at the faster methods of delivery, new development styles. These things often go hand in hand. You often can’t get those faster methods of development with rapid feedback and everything else without looking at, how do we change our entire development life cycle; trying to be stuck in a waterfall method doesn’t really get you that same acceleration that you can get when you start looking at, how do we automate everything and moved to DevOps.

Shimel: Got it. Got it. Now you broke up there a little bit back on – and I’m hoping people listening will be able to catch all of that. But let’s – so we may fill in. But let’s talk a little bit about the role of testing and that framework of app modernization. Obviously, testing is important, but how so and in what context?

Tarnawsky: So I actually see – you know, if we are taking older, monolithic applications and looking to migrate them towards micro-services, it’s a great opportunity for testing. You are putting things into small units that can be tested on their own. You get things like – let’s say you’re migrating to a _____ based _____ based service, you get the opportunity to describe it with _____ Swiger or _____ or open API. And you’ve got a contract there that you can then test against.This means that things now have the parameters, the what needs to be tested, how to test it, and it can be imported into many different test tools to help them start testing, but it’s smaller bits of functionality. So it’s a great opportunity to break things up and really look at how those can be worked with at a smaller level.

At the same time though, it also introduces new opportunities for more complex interactions that we didn’t previously anticipate. So let’s just say you’ve taken that big monolith. You want to expose micro-services to the rest of the world or indeed to other teams in your organization well, suddenly the integration that you had relied on in the past might not be the same ones that you are looking at using in the future. You need to start looking at how we test not just those smaller levels of the micro-services, but also looking at how we test each of those integrations over time.

One of my customers has a great analogy that they like to use in terms of the testing. They said when you’re testing a car, you don’t just test the car. You test little pieces of it. So you might start off by testing the spark plug. Then you might say we will integrate some pieces and see how those work together. We test the engine out. Then at some point in the future, we will put the engine in the car and we will test that as – you know taking it for a test drive, taking it for a spin, and make sure the entire end-to-end system works as well.

Shimel: Excellent. Excellent. Actually, that’s a great analogy. Great analogy. So Matt, another phrase we hear, and we’ve all been hearing it, a lot of us, in IT for a long time now, is service virtualization. I think people have a better handle on what we mean when we talk about service virtualization. But again, let’s lay a foundation. When you talk about service virtualization, especially in terms of app modernization and testing, what does that mean to you?

Tarnawsky: So service virtualization is where we take some sort of interface that we might have had that could be something silent rest. It could be something like Mqueue. It could be a legacy mainframe interface like Kicks. We provide some sort of mock that is going to handle the interactions with the interface. That can be coupled on the rest of the application. It starts to be providing us – I’m sorry.

It starts providing us with the ability to look around and – I’m sorry about that. Got myself a little bit jumbled there.

Shimel: No problem.

Tarnawsky: Basically, it gives us the ability to remove restrictions from ourselves. So if we had legacy items in our environment that we might not have in the cloud yet, well actually, we can do is we can say, well, look, that mainframe connection, that SAP connection, whatever it might be that’s in our current on-prem environment, we can virtualize that, we can house something that sits in the cloud. And in fact, our developers can have an entire environment in the cloud that is no longer linked to those legacy systems.

Shimel: Fair enough. So how does this all play out then, Matt? Right? So now we’ve got our little parts here and we’ve defined what we mean by this. In your world, where are you seeing sort of rubber meets the road, if you will, in terms of organizations deploying, employing, doing this kind of stuff? Make sense?

Tarnawsky: So we see all sorts of things. We do see people looking at that – we want to do a migration. So we are going to record various pieces of environment and have them available to replay. Just very, very basic style of creating virtual services, but it can be effective. And indeed, they can do the same sort of thing for their API testing as well and just say, “Have we migrated this correctly? Does it still have the same functionality we had last week when we had it on-prem as we got on the cloud now?”

That’s a very effective way to look at things. But equally, we see all sorts of interesting stories come up from customers, whether that’s looking to virtualize the way a third party – so we’ve seen customers look at things like Apple Pay or Experian or whatever, where they have to pay every time, they had that third-party service. Or indeed, that might just don’t have control over it and they want to simulate what happens if that third-party service responds or throws an error code or whatever.

We see customers who do some really – one of my favorite stories comes from a customer who was looking at testing out their credit card issuing systems. Now, you can imagine that as you’re looking at issuing a credit card, at some point you’re going to print a credit card. Now, just imagine test automation for that sort of thing. Do you really want credit cards popping out of the machine? No you want to be able to test things effectively, but not have these physical dependencies.

So what they did what they looked at the traffic that was going through that credit card machine, the issuing machine. They said, here we got a point where we can virtualize some things in our environment and remove this dependency that we currently have. We don’t want to print real credit cards. It’s a waste of time, waste of resources, and in fact, it slows that test automation down. So if we can virtualize that out, we can get faster feedback back to the development team. So that’s exactly what they did.

Shimel: So Matt, we recently did a webinar over on devopsy.kinsta.cloud you are probably aware of it, modernizing testing as apps re-architect. Is this the kind of stuff we are talking about?

Tarnawsky: Very much so. You want to make sure that your testing stays in pace with that re-architecting of the apps. A lot of that does come down to developers delivering fast from the cloud. And tests more and more need to be automated. That doesn’t remove the value of exploratory manual testing or anything like that. But we do see that need for testing to become more and more automated in the future as well, as this change happens.

Shimel: Absolutely. You know, another thing, and I get this a lot, Matt, when I’m traveling around the world. Is this a sort of – not to use the – abuse the term, but first world problems, right? Is this where… In terms of the market, is it sophisticated, large enterprises who already have legacy infrastructures, a history of service virtualization and so forth? Or is this something that’s really kind of more grassroots that’s happening across the board, across the globe, as organizations are starting to move to app modernization and dealing with the realities of having to test around this stuff?

Tarnawsky: So we see all sorts. Actually, the example I gave you earlier, the bank that was looking at the credit cards, was a fairly new bank here in the UK.

Shimel: It was? Okay.

Tarnawsky: They were – that they are very much based on looking at how they can do things in the cloud, trying to keep things as modern as they can. They are looking for all the latest techniques, all the newest tools that can help speed up their development and their time-to-market. So yes, we do have a number of customers using this stuff for legacy enterprise systems. They are looking to virtualize the way a mainframe, for example.

But equally, we see other customers come to us and say, “I want to accelerate my development and my testing as fast as we can. What can you do to help us?”

Shimel: Good. Interesting. You know, Matt, I mentioned when we started that the time goes pretty quick. We are coming up on the end of our time frame here. But for people who maybe want to get more information on this, where can they – where can we dig? I mean, I should mention that the webinar I referenced earlier is available on devopsy.kinsta.cloud and YouTube, a recording of it along with the slides. So people who are interested there should absolutely head on over and get that. We will try to include the URL in our show notes for today’s podcast.

But where else should they go, Matt? How do people get smart on this?

Tarnawsky: So I would invite them to come on to IBM.com, searching for Rational Test Workbench or Rational Test Virtualization Server, depending on whether they are interested in test automation or service virtualization, as a starting point. And we’ve got loads of white papers. We’ve got customer stories. We’ve got all sorts of things you can look at for more information just to see how other people have been doing things.

Shimel: Fantastic. Matt Tarnawsky, thanks for being our guest on DevOps Chat today. Pleasure to have you on. Hopefully we will have you on again soon.

Tarnawsky: And thank you very much for having me.

Shimel: All right Matt. Hey, this is Alan Shimel for devopsy.kinsta.cloud. You just listen to another DevOps Chat. Have a great day, everyone.

— Alan Shimel

November 30, 2018
DevOps Chat: JFrog Announces $165 Million Funding Round

In what may be the biggest round of investment yet in the DevOps space, JFrog announced today that it has closed its Series D round of funding totaling $165 million. The round was led by a new investor, Insight Venture Partners. Jeff Horing, co-founder and managing director of Insight, will join JFrog’s board.

JFrog, the developers of Artifactory and other artifact-related software, has recently taken a higher mission to develop a platform named JFrog EnterprisePlus, a first-of-its-kind, universal DevOps platform. According to JFrog, the money raised “will drive JFrog product innovation, support rapid expansion into new markets and accelerate both organic and inorganic growth.”

The company had raised something in the area of $65 million in previous rounds. It has also made several acquisitions to add both new functionality and geographical reach.

As readers of devopsy.kinsta.cloud are aware, we have closely followed JFrog’s progress over the years, as the company represents a good example of how vendors are growing and establishing themselves in the DevOps market.

We had a chance to sit down and speak with JFrog co-founder and CEO, Shlomi Ben Haim, about this latest news. Our conversation can be listened to below, followed by a transcript of our chat. Enjoy and congrats to the JFrog team.

Audio

Transcript

Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to a DevOps Chat, and we’re here breaking some big news this morning. The folks over at JFrog, makers of Artifactory and several other great projects and products, have announced what may be one of the largest rounds ever in the DevOps space, $165 million, I believe, but joining us is Shlomi Ben Haim, co-founder, CEO of JFrog, and he can tell us all about it. Shlomi, welcome.

Shlomi Ben Haim: Hey, Alan. Great to meet you again. Thank you for having me.

Shimel: Thank you, my pleasure. So Shlomi, as I mentioned earlier, exciting, big news coming from JFrog today. Did I get the number right, $165 million round?

Ben Haim: Yes. [Laughs] You got it right. It’s $165 million, series D.

Shimel: So first of all, Shlomi, congratulations. You know, raising any amount of money is never easy; raising this kind of money is truly an unbelievable task I can’t even imagine. So congratulations to you and Fred and Yoav and the whole team at JFrog on this accomplishment.

Ben Haim: Thank you very much, Alan. We are not taking it for granted and we are very, very excited. Thank you.

Shimel: Good. So Shlomi, I understand Insight Venture partners led the round, is that correct?

Ben Haim: That’s correct. Insight Venture led our series D. Jeff Horing will be the partner that will join our board.

Shimel: Excellent. And talk to us a little bit – they led but your existing investors participated. Any other new investors?

Ben Haim: Yes. So this round actually was one of the best experiences [laughs] we ever had in the landscape of fundraising. We had awesome partners reaching out to us throughout the, I don’t know, last three years, and we started to build a relationship with all of them. And one of the things that we wanted to make sure in this round is that we would have funds that understand late stage and understand mature companies with mature products in the market, and this is how we met Insight and some other great VCs. Together with Insight in this round, Spark Capital joined us with Alex Clayton and Geodesic, that you probably know, that have some presence in Japan. Other than that, Battery really supported this round. Battery is one of our current investors alongside Sapphire and Scale and Vintage and Bell Capital. Actually, most of our investors joined this round again.

Shimel: Excellent. Excellent, excellent, excellent. So Shlomi, you know, beyond the big number, talk to us a little bit about what does it mean for JFrog?

Ben Haim: Well that’s a good question because we were in this place when the company’s doing great and you are very – you are going very fast and very efficiently and the market is going, so it’s not just your business, it’s the whole market, the whole DevOps market is booming, and the fruits of our labors were something that we felt every day with all of our six products. And just three months ago we released a platform, the Enterprise Plus JFrog platform, which is an end-to-end solution to all kinds of binary, and we knew that this is the right timing to go big on the market and take it down because JFrog – as people are telling us, JFrog is everywhere. It’s about to be the standout of the DevOps industry. And now that we are planning some big things to the market we needed to support that with the right amount of funds and to build a great company.

Shimel: Sure. And, you know, Shlomi, we just spoke last week; you guys had acquired a company that was gonna help with delivering DevOps professional services, Trainologic. You’ve expanded all over the world, obviously, or are expanding, but really this brings a whole different scale to the equation, you know? We’re not talking about just opening outposts; with this kind of, you know, capital you can afford to make some major bets, right? Where do you see sort of major bets being made, major moves being made? Not just geographically, Shlomi, but in terms of focus areas?

Ben Haim: Yeah. So Ana and I will humbly say that we have raised the highest amount in the DevOps history, not just to create the news item but to create history. So JFrog’s vision is to make sure that software updates become liquid. Software updates should run like water in pipes. And with the product alignment that we got to, with the Enterprise Plus release, now that we have an end-to-end solution with the universal DevOps that keeps the freedom of choice in the hands of the developers, we are certain that this, alongside the presence we have in the market – we have over 4,500 customers – we are positive that JFrog will be the company or at least have the potential to be the company behind all the software updates in the world.

And this is the real pain of DevOps, this is what DevOps is trying to solve; we are trying to get software from A to B, and JFrog is following all the edges and support this binary flow and software distribution within our customer’s data centers and different sides. So I think that with this vision, to be the company behind all the software updates in the world, you have to dream big, you have to build big, you have to expand. You have to expand not just geographically as you mentioned, you have to expand with technology so you will be able to support whatever needs that will be raised, and you also have to take it seriously. It comes with a lot of responsibility.

Shimel: It sure does, it sure does. Shlomi, you know, they say a rising tide lifts all boats, and certainly, you know, look, we saw in the last – just this past month, GitLab raised $100 million round and $1 billion-plus valuation. We saw GitHub not that long ago purchased for $7 billion from Microsoft. And now we see JFrog with $165 million raised. What does this mean for the DevOps market in general, right? What does this mean for the DevOps market I mean for other companies and stuff like that?

Ben Haim: Well, you and I still remember the days that DevOps was not even a term, right? And of course there was no budget line called DevOps. So I think that the industry realized and acknowledged the fact that the biggest challenge is not the challenge of software; it’s the challenge of fast. We have to do things fast and we have to combine the human power with the machine power, and this is what DevOps is all about. You are right; this year was an amazing year for companies in this domain. So GitLab I think raised this $100 million last month, but these started with Xebia and then Mesosphere and then Sonatype and GitLab and of course the giant acquisition of GitHub, which I’m not sure if it’s DevOps or dev, but in any ways, same neighborhood. And this is exactly what I’m talking about.

The world belongs to those who are pushing software from build to production and we are all as consumers expect software to be up-to-date at any place, anytime in a secure way, and this is what we are doing. This is JFrog’s mission, and I think that VCs acknowledge that. I think that the market acknowledge that. I think that if you’re looking at Atlassian, which is for me the best example of building something big in the world of software infrastructure, if you look at their market cap we all see the same sign and the sign says this is going to be a big market.

Shimel: Yeah. It’s a huge market. So Shlomi, you know, with this kind of raise, we also have the opportunity to maybe move out of the comfort zone. So this is an entrepreneurial dilemma; do you double down on what you’re doing, doing well and do it better, or do you look to maybe in adjacent areas or that blend in nicely with what you’re doing now but expand the offering? You know, you drive the vision. You know, it’s tempting but also discipline requires focus on what you do well. What do you think about that?

Ben Haim: I think that it’s maybe the most popular entrepreneurial dilemma, but one very smart investor told me once, “I’m not here to invest in what he did; I am here to invest in what you’re going to do together with me.” And I’m still taking this very important sentence very seriously. We built a great business and a very solid business with awesome foundation and I think, Alan, you know that, the market knows that and, you know, giant companies are investing in JFrog every day. We are growing at a pace of 100 new logos as month, so we are very honored and very pleased to see that what we have created is growing, but it’s not even the tip of the iceberg. The whole idea of pushing software from the development machine to whatever edge is a big mission because it comes with high availability and it comes with a universal solution and it comes with security and it comes with automation and scheduling.

And you start to see the consolidation in the DevOps market; people start to understand that you need a code repository – this is a very important piece – and you need an artifact repository – and this is a very important piece – and on top of those two you start to build the layers of DevOps. So we are taking this field by field and layer by layer, but it’s just the tip of the iceberg. We will follow any edge and I think that it’s just the beginning. We didn’t even start to think about DevOps for IoT, which will also be a big thing five years from now.

Shimel: I think maybe even before five years.

Ben Haim: I agree with you, yeah.

Shimel: So let me turn it another direction. You know, one of the things I personally admire about JFrog is the culture that you and the team have built there. It’s great, it’s exciting, it’s energized. I can only imagine the buzz internally as a company around the race. Why don’t you share with our audience a little bit of insight. How has the team there reacted to the news?

Ben Haim: So, Alan, I – you touch [laughs] the very special, you know, spot in my heart when you speak about our team. I always thought that it’s great to build a company of 50 people or 100 people because you can preserve the culture, but now we are over 400 people and some of the folks are, you know, a result of M&A and acquisitions that other companies – great companies that joined us, and still we can protect what we call the JFrog codex and our culture and I’m very, very pleased to see it. Obviously, we didn’t share it yet with all the folks – we are going to do it on the third, on Wednesday – but we shared it with all the management, different tiers of the management.

The excitement is through the roof mainly because of the fact that everyone that walks in JFrog – you know what, not everyone – but 90 percent of whoever walks into JFrog is so humble and, you know, so focused on the day-to-day mission, and when something like this is happening it’s just – you know, it’s more than shocking news. It’s going to the mirror and look at the reflection and say, hey, we did something great and we built it together. And we say in JFrog, once we leap forward you won’t go back, but it’s not about that. It’s about once you leap forward together with your team you won’t go back, and I think that this is the significance of JFrog.

Shimel: Excellent, excellent. Shlomi, also – look, you spend most of your time I know now in the states, but JFrog is originally an Israeli company. This has also gotta be big news in Israel I would imagine. I don’t know if an Israeli company – I mean Israeli companies have had big exits, but this kind of raise, and you’re talking to us today from Israel. Can you give us a sense on that, of what does it mean within the Israeli tech industry, which is, you know, such a hot, hot space, but this has got to, you know, make some noise there, right?

Ben Haim: Yeah, absolutely. Well this is – you know, these are big numbers for any market, like I don’t know any other company in the landscape of DevOps that’s raised this amount and with these great partners, so I think it’s big news everywhere, but yes, you’re very correct. And, you know, the Israeli market, it will be a big news item, though there are companies in Israel that raised about $100 million, some of them even above $200 million, but there is something very interesting happening in the industry, the high tech industry in Israel. We were used to known for our technology, you know, the Israeli technologies and all the startups booming in this very small country, and then for products – so you heard about companies like Waze and so on – and now I see more and more Israeli entrepreneurs that are daring to dream big and to say “I’m going to build my own company to be public and to last forever,” and to stay there and not just in the next five years and then get bought by one of the giants, but it’s going to stay relevant for the rest of the years. And I see more and more Israeli founders thinking that way, raising money from late-stage funds, raising money with an IPO in mind – you know what? Not as a goal but as a milestone. It’s something that will structure the company to be bigger and better. And I’m very excited to be part of this industry as well.

Shimel: Absolutely, and you should be. So Shlomi, right there, I gotta ask; is that – is an IPO versus an acquisition the goal, the end game here or you’ll take that as it comes?

Ben Haim: You know, we think about the next act. For us, IPO is a very important milestone. It’s another way to raise money; to spend not from the funds but from the public, but it’s something that we’re looking at. Jacob Shulman, our CFO, joined us from Mellanox, which is a public company. We know what we are doing but it’s a milestone. If you ask me what is my biggest challenge, I want JFrog to be able to cross the $1 billion threshold before 2025. This is a very, very long run goal but, well, we are already at 10 years old JFrog so you can bet on us, keep your eyes open, and we will make it happen.

Shimel: Excellent. All right. Shlomi, we’re about out of time, but let me again say congratulations, mazel tov; just a real accomplishment here. But you know what? One thing I’ve learned with raising money, Shlomi, is it’s not anyone does you a favor. People don’t give you money ’cause you’re a nice guy or they want – you know, they do it because they see a way to make more money. So to me this represents more than anything a tremendous vote of confidence in what you’re doing there and what the potential return on investment is, right? So for that alone, really hats off to you and the team. I wish JFrog, you know, and you and the team fantastic success going forward. We’re all gonna be watching. Make us proud. And thanks for talking to us today.

Ben Haim: Thank you so much, Alan. I really appreciate what you do for us and what you do for the DevOps industry. It’s not taken for granted. Thank you so much for all your time and for giving me the opportunity –

Shimel: Yeah, my pleasure.

Ben Haim: – to speak about this again. Thank you.

Shimel: We will for sure. Shlomi Ben Haim, co-founder, CEO, JFrog just announced $165 million round led by Insight Venture Partners. Fantastic news. This is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. Have a great day.

— Alan Shimel

October 4, 2018
GitLab Joins Unicorn Club With $100m Raise

GitLab has become the latest member of the Unicorn club after announcing a $100m round of funding led by ICONIQ Capital. This latest round, a series D brings the total capital raise for GitLab to $145m over 3 years. According to the company it also raised their market valuation to over the magical $1B mark.

Some of GitLab’s success in raising this latest round of capital can be attributed to a raising tide lifting all boats. Microsoft’s acquisition of GitHub for $7.5B continues to make ripples in the software developer tools space. But while they share Git in their name, GitLab is not just another Git or GitHub imitator. No, GitLab has a far more ambitious mission. They actually want to be a one stop shop for a complete end to end DevOps solution. Using GitLab you can replace 6 to 9 different DevOps related tools. Or at least that is the vision.

I have always thought this was a tall order that would require a different way of building software to succeed. GitLab’s CEO Sid Sijbrandij thinks he has found this new method. Using open source, GitLab has an army of software contributors that donate their software to GitLab everyday. With monthly releases you can see the results of this philosophy with constant progress on all fronts at once.

While Sid realizes that every component or area of GitLab may not be best of breed today, it is his vision that it will be. So what does $100m buy you today to recognize this vision? Well you can hear it right from the ~~horse’s~~ unicorn’s mouth. I sat down with Sid to discuss the raise, the future of GitLab and the market in general.

I have had the pleasure of interviewing Sid before. He has some very good ideas on where the market is and where it is heading. Below is our conversation, enjoy!

[wpvideo lvF0Ey0B]

— Alan Shimel

September 21, 2018
DevOps Chat: Modern Applications with SignalFx CEO Karthik Rau

Monitoring has come a long way since the days of 2 a.m. alerts, with automation and analytics now integrated in—and integral to—the life cycle of modern applications. It’s a topic Karthik Rau, CEO of SignalFx, knows well, and one we discuss in this latest DevOps Chat.

In its three years of selling, SignalFx has grown a whopping 300 percent year over year—an astounding number, even for a startup.

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

Alan Shimel: Hi, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Today’s DevOps Chat features Karthik Rau, CEO of SignalFx. Karthik, welcome to DevOps Chat.

Karthik Rau: Thanks, Alan. It’s great to talk to you again.

Shimel: Always a pleasure to have you on. So, Karthik, let’s just do a little setting the base here, baseline setting. And I’m gonna assume most of our listeners have at least heard of SignalFx, but maybe some haven’t and maybe some have heard it but they’re not sure exactly of who SignalFx is. Why don’t we start there?

Rau: Sure, Alan. SignalFx is a monitoring and operational intelligence solution for the developers and operators of cloud-native applications. Our founding team, my cofounder and our original engineering team, all came out of Facebook and were responsible for building the monitoring systems at Facebook, back when they had a “move fast and break things” culture, which today everyone calls DevOps, but, back then, they didn’t really have a term for it. So, at a high level, what we do different from everyone else is we are focused very heavily on the analytics part of the monitoring problem. We collect data – time series, telemetry data – across the customer’s entire environment, from the hardware to the middleware to the application, all the way up even through the API layer, and we apply real-time statistical models around that data to identify patterns that are unusual and different, and alert on those trends proactively so that customers can get ahead of issues and be more proactive in their monitoring, rather than reacting to a bunch of noisy alerts.

So our customers are able to, No. 1, get a much better handle of their distributed cloud-native application architectures, understanding the patterns, what’s happening. They’re able to detect issues as they emerge, which is very important in today’s environments because most people are pushing changes out a lot more aggressively, and so you wanna detect changes immediately, rather than wait and discover stuff after you’ve made a number of changes. And it’s particularly important for today’s application architectures where you’ve got a lot of bursty workloads, like with containers, where you’re spinning up and spinning down capacity in minutes and you really need your monitoring systems to be (a) real-time and discover components immediately and then (b) be a lot more sophisticated in finding issues as they happen.

Shimel: Excellent. And, Karthik, you know, I should also mention that, in terms of UI, SignalFx is one of the best UIs, web-based UIs that I’ve ever seen. And I’ve looked at a lot of applications, a lot of programs, over the year – over the years. Year? I wish it was “year.” And, you know, so – and I’ve told you this before. I’m just think whoever designs the interfaces there is a rockstar, so just mention that, but –

Rau: Yeah. Thank you.

Shimel: You know, we spoke a little bit off-mic, Karthik, and we were going over what are some of the new metrics coming out of SignalFx, how business is going, and you mentioned some really eye-popping numbers, right? First of all, you guys are showing something like 300 percent year-over-year growth for the last couple years, which is – you know, everyone will say, “It’s a startup; they’re supposed to grow like that,” but, dude, until you’ve done it, you haven’t done it, so that’s an astounding number. But also a big move into large enterprises. Is that correct?

Rau: Yeah. So, yes, absolutely. So we’ve been, as you’ve mentioned, tripling our business year over year, since we – over the past year, but significant growth even above that in the early years. We’ve only been selling for about three years. Our customer base is focused quite a bit on mid- to larger-size companies, so we’ve always been focused on larger accounts, whether that’s the web-scale players, who are operating large-scale applications with four or five nines availability requirements, but also a lot of the enterprise accounts, who what we’ve been really excited about is they’re really moved wholesale into cloud and cloud-native application architectures. And we’ve seen that trend accelerate over the last two or three years, so that’s been a large area of success for us. You know, we’ve got Fortune 500 customers across many verticals – media, retail, financial services, industrials, transportation – so we’re definitely seeing that trend accelerate across the enterprise, not just in a handful of verticals.

Shimel: Absolutely. But, Karthik, what about for the person out here listening to this, right? And he says, “Wow, that sounds great. I love what Karthik says they’re doing and the Facebook kinda background and all of this great stuff, but I’m not a unicorn. I’m not even a large enterprise.”

Rau: Well, I think that everyone today is trying to build software quickly, right? Gone are the days where you have a three-year development cycle and you release software and hope you get it right. It’s just not gonna work in today’s world of web services and your competition are tech companies that are moving at lightning speed. So the issue isn’t really – the world is changing. The way people are building and releasing and managing software is fundamentally different.

And what SignalFx does, the analytics around SignalFx, you can look at it in two ways. One way is, yes, if you’re a large environment, you absolutely have to have it to reduce noise, but another way of looking at it is you could be a small environment and you wanna have a more predictive way of discovering issues, as they emerge, so that you too can move fast without breaking things, right?

And if you look at it that way, having the kinds of capabilities that SignalFx provides are critical, even if you’re a department within a big company or you’re a startup with 50 people or 20 people. You still wanna be able to do the proactive analysis of, “Hey, this code push that I just rolled out, a canary release, is unusual relative to the rest of my application. And maybe that’s indicative of a problem with my code and I wanna roll it back before rolling it out across all of my users.” Right? You don’t have to be Facebook-sized or Google-sized to have that problem. You’re just building a modern application.

So that’s why we do have customers across segments. I mean, our focus is certainly on the larger accounts, but we’ve got a lot of departmental deals within enterprises. We’ve got a lot of startups that are also using us, who care about having a more predictive approach to monitoring.

Shimel: Yeah, no, you know, I think the key there – and you mentioned the word, Karthik, and it’s funny; it’s a word I’ve been hearing over and over again. And that this term of the “modern application.” I don’t care whether you’re big, small or Goldilocks. The modern application, as we call it, right, demands certain things, and one of them is obviously monitoring, but also modern applications demand automation, real-time type of data flows and insight. And it’s not just the guys who develop once every few years – that certainly is not a modern application – but it’s also more than just how frequently you update your code. I think the modern application, you know, what goes are in, the kind of stuff, or at least one element of it is the kind of stuff you’re talking about with SignalFx. Right? These go like hand in glove.

Rau: Yeah. Absolutely.

Shimel: So I think that’s – so, to me, more than size of company. I mean, that’s almost a determining factor. Another item I just wanted to mention on the – or bring up on SignalFx itself, as a company, is you guys recently announced a rather large round of funding as well.

Rau: That’s right, Alan. On the backs of all of our success, we continue to build out our product and continue to accelerate our go to market. We just closed a $45-million Series D round in May and we’ll be using that to continue our investment in R&D. We’re continuing to expand globally. I think I’d mentioned to you offline here that we’ve just expanded into Europe. We also recently expanded into Australia. We’ll continue our expansion geographically, so, hopefully, a lot more people across the seas will hear about us and see us, in the coming quarters.

Shimel: No doubt in my mind about it, Karthik. I can tell you, from – when I look at devopsy.kinsta.cloud’s demographics and metrics and analytics, it blows me away that only about 36, 35 percent of our audience these days are U.S.-based.

Rau: Mm-hmm.

Shimel: About 31, 32 are based in Europe. 15 percent in India. Australia is probably the fourth or fifth largest country, for instance, for our readers. So –

Rau: Yeah, that’s right.

Shimel: – you know, the thing about this market is it’s truly, truly a worldwide market. And I know, Karthik, if you’ve had the chance to go to China recently, but I was there for Interop China last month, talking about DevSecOps, and I will tell you that the DevOps market in China is exploding. I mean, just there’s a lot of people there, obviously, as there are in India, but DevOps is really catching fire.

And, as you and I were talking about offline, Karthik, it’s one thing if you’re chasing that crowd or you’re chasing that wave. In the case of SignalFx, it’s a beautiful thing, where, maybe when you did launch, you were a little out ahead of the market, a little out ahead of the state of art, but they’re catching up to you now, right? They’re coming. And it’s good to be there, waiting for them.

Rau: Yeah, absolutely. The market – what’s been most interesting about – you know, at SignalFx the last several years, has been, when we launched the company three years ago, our – what we did that was so different from everyone else is we had this real-time streaming analysis engine, streaming analytics engine, that could apply these sophisticated models within seconds across large data sets and help you be a lot more predictive in identifying issues. And no one else was doing it that way and still no one else is doing it that way. And, at the time, people would ask us questions of like, “Well, what does it really matter if you can do things in seconds versus minutes? ‘Cause the human attention span is only minutes and if you wake up in the middle of the night, it might take you minutes to go and deal with an alert.”

Well, that was kind of in the old days. Now what’s happening is there’s so much more automation happening across the entire operations landscape. I mean, people talk about it as infrastructure as code, right? You basically automate the entire end-to-end process as much as you can. And, more and more, there are these frameworks that enable greater automation, like Kubernetes, and what we’re finding now is people are really recognizing that, “Maybe we don’t need roomfuls of NAC engineers waiting to find a yellow light or a red light to then go and manually invoke a script from a run book, if we can just automate it.”

Well, guess what? If you’re gonna automate a remediation like that, garbage in, garbage out. You need quality in. You need to have quality signals. You need to be able to untease signal from noise and you need to be able to do it quickly. And if you can do it quickly, then you can automate quickly and you don’t – the whole notion of having a human wake up and spend minutes orienting themselves goes out the door ’cause you can just – or having the roomful of NAC people responding to it goes out the door. You can just automate it. And then the capabilities of SignalFx then are very unique and very critical to enabling you to drive this end-to-end automation.

And what we’re finding is now more and more of our customers and marketplaces recognizing this, as they’re embarking down this path of leveraging microservices and automation around microservices and infrastructure as code. Having a system like SignalFx, with its real-time analytics, is absolutely critical. So it’s been fascinating to see that evolve over the last few years.

Shimel: Yeah. No, for sure. You know, Karthik, it was interesting. I saw an interesting metric today. Something – I forgot who it came out of – Gartner or someone. Within two years, something like two-thirds of cloud deployments will be container-based, which kinda blew me away, to tell you the truth. Have you heard anything like that?

Rau: I mean, that’s an incredible metric. I mean, I would say we’re certainly seeing a tremendous amount of interest in containers. Well, it’s gone from interest to actual deployments, right? So, two years ago, there was a tremendous amount of interest in it. Nowadays, I would say that is the de facto new architecture, so I think the keyword there is “new,” right? So two-thirds of new deployments, I totally believe that, that that will be the case, 100 percent.

Shimel: Crazy. I mean, we talk about internet time and the time crunch and it seems to be accelerating like global warming is and climate change is, but the idea that we’d see that kind of number in that kind of time just kinda blows me away. So, Karthik, we spent a bunch of time with this stuff, going over the SignalFx, a little bit about the market, right? Let’s take a look at a crystal ball and gaze into where do you see SignalFx, let’s say, going over the next, let’s say, 18 tp 24 months?

Rau: Well, we continue to invest across our business, right? So our focus right now is we believe there’s a giant problem that needs to be solved in the industry, which is, “How do you get better visibility and monitoring around the new stack? And then, beyond that, how do you get better visibility into how your operations are impacting your business?” So, as I mentioned at the top of this podcast, we think of ourselves as monitoring and operational intelligence for modern applications, so one of the things that we – we see all our customers go through a similar progression, where you’ll start doing the infrastructure monitoring for this new world, where you gotta look at the entire microservice, versus an individual node, and you start to get into application and look at application performance issues.

But then, very quickly, customers typically start to look at how are all of these metrics affecting their business, right? You know, “How many of my partners are making API calls in my services? And who are my most expensive partners and my least expensive partners?” Or, if you’re a SaaS vendor and you wanted to do a gross-margin analysis by customer, all of the data already exists in your monitoring system, and we see more and more of our customers extending the use of these systems to answer broader questions around operational intelligence.

So that’s kind of – those are the three sort of key pillars of what you use a system like a SignalFx for, right? It’s infrastructure monitoring, it’s application monitoring, and then it’s operational intelligence. So our plans, as a company, are really focused around those three pillars. You need to invest in product to support all of the use cases around those three areas. And then continuing to invest in our sales and marketing team so that more and more companies out there can benefit from what we have to offer. So that’s our focus over the next 18 to 24 months.

Shimel: Fantastic. And, as we spoke about earlier, it’s nice to be out in front of the market, but, Karthik, your job, as the CEO, if you choose to accept this mission impossible, is how do you stay out front of it? You’re right? How do you know – how do you – I mean, you think containers are gonna be dominant, right, so you wanna put that cloud-native dominant. What do you think is sort of next big things coming out there?

Rau: Well, in our space, I think the most fascinating new set of technology is around service mesh. You know, as more and more of the world moves toward leveraging containers and orchestration frameworks like Kubernetes, the service mesh is gonna be a really interesting way of automatically getting visibility into all of the flows between all of these different microservices, having a control plane to operate against all these microservices. And it’s still relatively young. It’s still in its infancy, but there’s a lot of great stuff happening there, you know, what you see Lyft doing with Envoy and Istio and LinkerD. There’s just a lot of really interesting stuff happening there.

And the theme here is, as developers own more and more of running their applications and the runtime, what you’ll find is more and more of the stuff that used to be this black-box, proprietary thing that vendors would come in and do in the runtime are just becoming available as a part of the core services. So, in the case of service mesh, a lot of the instrumentation of metrics and traces and monitoring data is just you’re gonna be able to get it by virtue of running in a Kubernetes-style environment and you’re not gonna need these expensive, proprietary agents to come in and collect that data for you.

So that’s great for customers. It creates a standardized mechanism of data collection and it provides a lot of automatic instrumentation, which is great for customers. Of course, then that just begs the next question, “Well, what are you gonna do with all that data?” So we’re focused on ingesting more and more of these new types of data from these new frameworks and making it even more – the more data we get, the more powerful and rich the context we can provide around our alerts and algorithms and dashboards, so we’re really excited to see that trend continue.

Shimel: Very cool. Karthik, we’re about out of time. We’re probably over time here. I apologize for keeping you on so long. But, hey, man, you guys are kicking butt and taking names, and congratulations. For anyone listening out there who hears Karthik talk about growing 300 percent at SignalFx year over year and raising $45 million and it sounds like, “Well, la dee dah,” I’ve been there and I can tell you it’s not easy. So congratulations. Keep up the great work and we’d love to check back in –

Rau: Thank you, Alan.

Shimel: Let’s not wait a year to check back in with SignalFx. Let’s have you on here sooner than later.

Rau: Absolutely. Let’s do it again soon, Alan. Sounds good.

Shimel: Karthik Rau, CEO, cofounder of SignalFx, our guest here on DevOps Chat. You’ve just listened to another DevOps Chat. Have a great day, everyone.

— Alan Shimel

August 13, 2018