devopsy.kinsta.cloud

Tag: devops chat

DevOps Chat: ChefConf Update with Chef’s Nell Shamrell-Harrington

2019 is shaping up as a “coming home” year for Chef. After recently reaffirming its commitment to an open source strategy, the company is gearing up for the best ChefConf yet. ChefConf, scheduled for May 20-23, is coming home to Seattle and many of the Chef favorites including Adam Jacobs, John Willis and more will be speaking.

I had a chance to catch up with Nell Shamrell-Harrington, principal software development engineer and community engineering lead at Chef, who gave us a great preview of the whole event as well as her own presentation, and shared what her most anticipated sessions and activities are.

You can still register for ChefConf, as well as get more information at: chefconf.chef.io/

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

Transcript

Alan Shimel: Hello, everyone, this Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat.

Today’s DevOps Chat is all about the upcoming Chef Conference, and I’m happy to be joined by Nell Shamrell-Harrington, Principal Engineer at Chef. Nell, welcome to DevOps Chat.

Nell Shamrell-Harrington: Hello, Alan! Greetings from Seattle. It’s fantastic to be here.

Shimel: Yes, it is. How’s the weather in Seattle?

Shamrell-Harrington: Surprisingly sunny today, and it wasn’t raining when I came in, so pretty darn good for Seattle in April.

Shimel: Absolutely. Well, look—in April, April showers. But, you know, the whole weather in Seattle thing is a bit of a fallacy. You know, they get—

Shamrell-Harrington: What I tell people, when they ask me does it rain a lot, I said, “Yes, but it’s not, like, soaking rain. There’s a constant mist in the air that gets in to your bones and makes you cold.” So, you learn to deal with that, but yep, greetings from beautiful for today, at least, Seattle.

Shimel: Good for—[Laughter] good for you. Alright, so now, the big news is, we are, what, about a month, maybe a month and a week, a month and 10 days out of ChefConf, right?

Shamrell-Harrington: We are indeed. I need to write my keynote. [Laughter]

Shimel: I would say, let’s get started, yeah—might be a good idea. And this year, after ChefConf having kinda wandered around for a few years to Chicago and Austin and I think Santa Clara I was at one and a bunch of other places, you guys are coming home to Seattle, right?

Shamrell-Harrington: We are indeed, and we are very excited about this. We look forward to welcoming the entire Chef community to our home of Seattle.

Shimel: Absolutely. And when we say coming home now, you know, I think it’s figuratively and literally and kinda philosophically.

Shamrell-Harrington: Absolutely.

Shimel: As ChefConf really represents a sort of coming home for Chef in a lot of ways, do you agree?

Shamrell-Harrington: I agree. We made the recent announcement—which I know you covered on a previous episode—about 100 percent of our product code now being open source. And one of the reasons we did that was, Chef was created through the open source community. Chef—I mean, the open source community built every piece of the foundation that Chef stands on, so we are returning to those roots with open sourcing 100 percent of our product code and a lot of the discussion about that will be at ChefConf in our geographical home as well.

Shimel: Yep. And, you know, I mean, the open source, reaffirmation of the open source commitment, I think, is one part of it. I think another part of it, though, Nell is—you know, look, I’ve run devopsy.kinsta.cloud now for five, six years, right? And when I first got into DevOps, you know, Chef was one of the blocks of granite, if you will, upon which the DevOps foundation or the DevOps world was kinda built.

And over the years, you know, there’s been a lot of shiny toys that have come, as such happens in the tech space, right?

Shamrell-Harrington: Of course.

Shimel: And you sort of say, “Yeah, you know, that was—you know, Chef almost was old and what is it doing to stay current? Is it still relevant? And there’s Kubernetes” and all of these things. But to me, this ChefConf represents a bold, provocative, confident Chef coming, in their home court, kinda like the Hawks, right, coming out of the—

Shamrell-Harrington: Very much so, or their home stadium, but yes.

Shimel: – with the 12th man, and saying, “Hey, man, we’re still here, we’re still kicking, but we’re still innovating, we’re still true to our roots, and we’re still helping people with DevOps.” Fair?

Shamrell-Harrington: Absolutely. I believe that is completely fair. We are walking this DevOps journey together, both the Chef community and Chef the company as well. And this is bringing us back into sync.

Shimel: Cool. So, let’s dive in a little bit. You mentioned the open source commitment, and we have covered that before. Give us some—you know, and you’re gonna keynote, right?

Shamrell-Harrington: I am, indeed. I’ll be keynoting, I’ll be first up on day two. So, make sure to be there on time.

Shimel: Can we get a little preview without getting in trouble?

Shamrell-Harrington: Absolutely, we can. So, I will be discussing developing software through a community. When I was starting to brainstorm this talk, I was worried that—you know, I’m a Principal Engineer. I’m very used to giving technical talks. I was worried people would respond with, “Why are you giving a cultural talk?” And I realized, open source community, it’s not cultural or technical, it’s both. And that’s really where the magic of working in open source Chef has come.

We work on fantastic technologies, we work with fantastic technologies including Kubernetes, Terraform, and so many more, but we do it with amazing humans.

Shimel: Yeah, absolutely. Now, Nell, you’re not allowed to mentioned your keynote, but give me what you’re looking forward to, the top three things at ChefConf this year that you might be looking forward to. And if you wanna do five, feel free.

Shamrell-Harrington: Absolutely! Well, for ChefConf itself, I’m really looking forward to the Community Summit on Monday, May 20th. That’s when we get together, we hold a bunch of open spaces, we talk about what Chef is doing and where we as both a company and a community wanna go.

So, there’ll be a lot of talking at the summit on Monday, and then on Thursday, we have our hack day. It’s not a competitive hackathon, it’s more people getting together in groups and building something together. So, after we talk on Monday, we’ll start building what we’ve discussed on Thursday, and I hope to see everyone there.

Shimel: Great. So, that’s one.

Shamrell-Harrington: Right.

Shimel: What are some of the others?

Shamrell-Harrington: As far as the sessions go, we have sessions from people from retail, government, banks, major cloud providers, and so much more. A few that I am particularly looking forward to are “A Habitat for Democracy.” That’s going to be by Chris Alfano of Code of America. They use Habitat to help them—they use Habitat for civic hacking, essentially. So, looking forward to hearing more from him.

Another one is, “FIPS Doesn’t Have to Be a Four Letter Word” from Keith Walters of TapHere! FIPS is Federal Information Processing Standards. It is as boring as it sounds, but it is extraordinarily important for our government customers, especially those who work in particularly sensitive areas of the government.

And then the third one, I mentioned how Chef, it doesn’t compete with things like Hashicorp, Terraform, or Kubernetes, it works with them. And one talk I’m particularly looking forward to is, “Terraform and Chef.” That’ll be by Seth Lippman and Andy Herm of Oracle.

Shimel: Very cool! You know, I will say, FIPS may not be boring, but it is expensive. [Laughter]

Shamrell-Harrington: Very.

Shimel: In my previous life, we had to have our information assurance, as the U.S. Army calls cyber security, our information assurance solutions FIPS certified for the encryptions and stuff. And that was an ordeal, to say the least, so, I’m interested to—I’d love to listen in on that one.

You know, you mentioned Terraform. There’s a lot of stuff coming out of the Linux Foundation recently now—

Shamrell-Harrington: Absolutely.

Shimel: – between Cloud Native and now this new CD Foundation that’s spun up out of Linux Foundation. It really is, you know, this whole move to Cloud Native is, in many ways, in my mind, anyway, Chef and some of the foundational work you guys did kinda laid the groundwork for the move to a Cloud Native world.

Shamrell-Harrington: Very much. You know, the groundwork, the reason Chef was founded, the reason Cloud Native was founded is, we had this still radical idea that working with technology did not have to be as painful as it normally is.

I remember I reached out to Gene Kim on Twitter after I read The Phoenix Project and I told him, “You know, it actually made me physically cry,” the first half at least, because it was so familiar. All that pain of dealing with both technical debt and cultural debt.

And what we’ve said at Chef, what Linux Foundation is saying, what other Cloud Native foundations are saying is—there is a better way. It does not have to be this painful. And we’re working to make a world where it’s not as painful as it has been to run technology.

Shimel: Amen. You know, I remember sitting with Gene Kim reading a manuscript of Phoenix Project, and you know, those characters in there are composites of real people.

Shamrell-Harrington: Oh, yes.

Shimel: And when you—you know, when you think back to who the real people are, I mean, it is dead on. I mean, truth is truth is truth.

So, I’m assuming there are gonna be people in our audience who are absolutely attending ChefConf, but there are also people who have attended them in the past, but then there’s also gonna be a lot of people who have never attended a ChefConf listening in. And, you know, for those who haven’t—shame on you.

Shamrell-Harrington: [Laughter]

Shimel: [Laughter] But beyond that, you know, you’re missing a great time, because it’s not all sessions, ChefConf.

Shamrell-Harrington: Very much.

Shimel: ChefConf is very much a community, a bit of a love fest, if you will, around Chef, right? And there’s always some great social activities. Can you give us a preview, maybe?

Shamrell-Harrington: Sure. Two of the ones I’m looking forward to, I believe it’s on Tuesday, we’ll be holding game night. We started doing those at ChefConf a few years ago, and I’ve always appreciated it. I have hearing loss, so, when I’m in a big, crowded, very loud party, I can’t have conversations with people, because I’m only getting every third or fourth word, depending on what frequency their voice is.

But with game night, it’s quieter. People are more focused, there’s something to do. I’ve met coworkers—or people who became my coworkers a year later through game night. It’s a wonderful way to connect on a deeply personal level with other attendees and other employees of Chef.

Shimel: And it’s fun.

Shamrell-Harrington: It’s absolutely fun. I think we’re gonna have, something we’ve traditionally had a Chef game night has been a gamed called Artemis, which is—I’m gonna get in trouble for saying this, but it’s kind of like a Star Trek LARP without actually being Star Trek. [Laughter] But there’ll be board games as well, card games, Adam Jacob always runs a Dungeons & Dragons campaign. It’s gonna be a wonderful world of geeky fun.

And then, on Wednesday, if kinda the traditional party is more what you enjoy, we’ll be holding the community celebration. And because we want to highlight the wonderful things Seattle has to offer, it will be catered by Tom Douglas. For all you foodies out there, you know that’s a very, very big name, both in Seattle cuisine and nationally and internationally.

And we have two classic Seattle bands playing. The first is Mudhoney, and the second is Deep Sea Diver. They will be playing the celebration, and we are very much looking forward to hearing them and sharing that with our community.

Shimel: So, providing a little translation in the background, right? If Tom Douglas is there, there’s a good chance there might be some killer salmon.

Shamrell-Harrington: Absolutely.

Shimel: He makes—I was actually privileged, he did—I forgot what event or gathering I was at. But they brought Tom in, and he showed us how to fillet a salmon.

Shamrell-Harrington: Oh! What a wonderful experience!

Shimel: Yeah, that was pretty cool. And then, of course, we went to one of his restaurants for dinner, and it wasn’t terrible. But beyond that, the Chef party—and that’s usually like the last night or the night before the last day kind of thing.

Shamrell-Harrington: Yeah, it’s the night before the hack day.

Shimel: Yep, and that’s always a great party, because by then, you know, the sessions are in, people have networked around a bit, have talked about a lot of the technology, and it’s a good time to have a good time, right?

Shamrell-Harrington: It is, absolutely. Whenever I’m speaking at a conference, I always enjoy the conference after my talk much more than the conference before my talk.

Shimel: Right. Well, because before, you’re all tensed, keyed up on doing that. You know, Nell, you mentioned Adam Jacob, and I’m sure some of the folks sitting out there are saying, “Well, I heard Adam’s not the CTO any more. What’s he doing there?”

Again, I think it talks to the power of Chef. I think it talks about Chef reaffirming its roots and all of that. It’s that—yes, Adam is not the CTO any more. He’s out doing his Foundation thing. But he is going to be there, he is presenting, if I’m—

Shamrell-Harrington: He is. He’s presenting on day two as well.

Shimel: What other kinda—John Willis is speaking as well. John, I think, was, I wanna say, employee eight or nine at Chef back in the day.

Shamrell-Harrington: Mm-hmm.

Shimel: And he’s also speaking, as well as he will be there on behalf of Digital Anarchist, which is a video platform John and I partner on—

Shamrell-Harrington: Oh, great!

Shimel: – and we’ll be doing interviews. Yes, we’ll be doing interviews all through ChefConf, so look for the little video set, if you wanna say hello to John or check out some of the videos we’re shooting.

What about training, though? Isn’t there training or something going on earlier?

Shamrell-Harrington: It is, indeed. Monday, which is the day of the Community Summit, along with the Community Summit, we’re running several training sessions. So, if you wanna learn more about Chef, you wanna learn more about Chef and Kubernetes—all sorts of topics. If you wanna get hands on before the sessions begin so you get familiar with the technologies that people are going to be presenting, that’s a great way to do it.

Shimel: Absolutely, absolutely. So, you know, Nell, interesting—look, you’re a perfect person to speak to the ChefConf crowd, right? Because it is a fairly engineering focused crowd, right?

Shamrell-Harrington: It is. It’s historically been primarily practitioners, though that is starting to change. We’re getting what we call decision makers as well, but it is primarily an engineering crowd.

Shimel: You know, someone could be a practitioner and a decision maker.

Shamrell-Harrington: Absolutely! [Laughter] Absolutely. And they make the best decision makers.

Shimel: I guess they call that diversity, but anyway [Laughter]—in a funny kind of way. Anyway, but there’s really something for everything at Chef there. What I’m trying to get at is, I don’t want people listening to this who are saying, “Well, I’m not geeky enough for that” or, “I’m not an engineer” or, “I’m not a developer,” right? If you’re at all interested in how software is getting done, how today’s winning teams are doing it—I mean, there’s something there for you at Chef.

If I can ask you—and we didn’t talk about this beforehand, so I don’t mean to put you on the spot—give me what you think is one session that, frankly, you don’t have to be an engineer for, and you’ll still get a lot out of it.

Shamrell-Harrington: The one I would recommend is, “Bridging the Great Divide: Using Chef as a Spark for DevOps.” That is going to be given by Brittany Woods of CARFAX, and I believe will illustrate not just their technical transformation but their cultural transformation, because the two of them go hand in hand.

Shimel: Absolutely. I gotta tell you, to this day still, one of my favorite ChefConf presentations was the guy from, was it Alaska Air, or Air Alaska? I always mix those—

Shamrell-Harrington: It’s Alaska Airlines, yeah. The keynote a few years ago?

Shimel: Yes.

Shamrell-Harrington: I remember that, the CTO of Alaska Airlines. That was one of the best ones I’ve ever seen.

Shimel: It was. That was a really good one. Anything else we wanna highlight?

Shamrell-Harrington: I would say, if you deal with technology at all, whether that’s as a developer or as an engineer or something else entirely, ChefConf is the place for you. We are obviously going to be highlighting Chef solutions for how to do technology better, but that’s not the only thing we’ll be doing. If you wanna meet a lot of other people who are having the same struggles as you, solving those struggles in new and different ways, please come to ChefConf.

Shimel: Excellent, excellent. You know what we haven’t done, though, Nell? We never told anyone where to go to get the information.

Shamrell-Harrington: Ah! Head on over to—let me check it real quick—ChefConf.chef.io. Or, if you Google ChefConf, you should get the correct ChefConf. If you see that it’s a conference for food chefs, that’s probably not the right one, [Laughter] but check out ChefConf. It’s in Seattle at the end of May, and we would love to see you there.

Shimel: Absolutely. And there’s still—there’s still tickets, I mean, you—

Shamrell-Harrington: There are absolutely still tickets.

Shimel: Cool. Hey, Nell Shamrell-Harrington, thanks for being our guest on this episode of DevOps Chat. Continued success with Chef, and looking forward to a rock and rolling ChefConf.

Shamrell-Harrington: Thank you so much, Alan. Great to be here, and looking forward to seeing everyone at ChefConf.

Shimel: Fantastic. We’ll talk to you soon. This is Alan Shimel for devopsy.kinsta.cloud with this update on the upcoming ChefConf conference. You can get more information at, I guess it’s ChefConf.chef.io, or just Google ChefConf.

Until then, or until next time, you’ve just listened to another DevOps Chat.

— Alan Shimel

May 1, 2019
DevOps Chat: Digital Transformation with Exadel’s Jonathan Fries

In this DevOps Chat, Jonathan Fries, VP of Engineering and Digital Transformation at Exadel, tells us about the new Innovation Lab by Exadel—a place for organizations to accelerate their transformation. We also talk about the state of IT in general from his perch at Exadel, a company with 20 years of empowering IT.

You can find out more about the Innovation Lab at exadel.com/innovation-lab/.

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, and you’re listening to another DevOps Chat. This episode of DevOps Chat features Jonathan Fries of Exadel. Jonathan, welcome!

Jonathan Fries: Hi, Alan. It’s great to be here.

Shimel: Hey, it’s great to have you here, Jonathan, and I wanna thank you. It’s always nice to have a new company coming up on our chats here, so it’s—you know, some fresh blood for the audience. I assume most of our audience is not familiar with Exadel, so why don’t we start with that, Jonathan? Tell us a little bit about Exadel.

Fries: Sure. So, Exadel is a global software engineering services firm. So, we help our clients write software. We have—we’re a global company, so we have offices in Eastern Europe, Belarus, Lithuania, Poland being kinda the big ones where we have our offices in Europe. And, you know, we help clients in a variety of areas. Probably our big verticals are health care, finance, transportation, media and entertainment, and high tech. And, you know, we have some really good clients in those areas. Health care, McKesson is one that people have heard of. Finance, we work with Deloitte. In the high tech world, we have HP and Google as our clients.

So, we’re doing offshore development for a lot of it. We have teams that are either all in Europe or usually a hybrid of some people here in the U.S. and some people in Europe. We’ve got about a thousand developers in Europe, so that’s where a lot of our work gets done. We’ve been around for 20 years, and so yeah, that’s a bit about Exadel.

Shimel: Another overnight sensation, huh?

Fries: Pardon?

Shimel: I said another overnight sensation.

Fries: [Laughter] Yeah, it’s been a gradual sort of buildup of working with clients and, you know, getting to work with a lot of interesting companies and them recommending us to others.

The name of the company actually comes from a combination of excellent and delivery. I always think that that’s an interesting fact to bring up, and I think it’s an important part about kind of who we are and where we come from and how we got that list of clients. You know, we’re all about building really great products, software products for our customers, and that’s how we’ve grown the business.

Shimel: Sure. So, and Jonathan, you know, kidding aside about overnight sensation, that’s the right way to build the business, right? You don’t just—I mean, yeah, everybody wants to be a unicorn, but unicorns are mythical, right? [Laughter]

Fries: [Laughter]

Shimel: [Cross talk] the world and all of that, so good for you guys. But you know what I didn’t mention is, what exactly—and just sharing with the audience, what’s your position with Exadel?

Fries: My title is Vice President of Engineering and Digital Transformation. So, my background is in the software development world doing software development, leading teams, eventually sort of managing engagements and things like that, and also today heading up the digital transformation practice inside of Exadel.

So, my background comes from the technology world and software development, and that’s why I’m proud of—I’m proud of our engineering capabilities and what we’re able to do for customers.

Shimel: Good for you, good for you. So, Jonathan, you know, digital transformation is such a buzzword today, right?

Fries: Yep.

Shimel: We’ve all heard it, you know, and the one thing I’ve learned is that, for many organizations, you know, digital transformation is hard, right? I’ve heard so many people say, “Well, this wasn’t as easy as it was made out to be.” And I think one of the issues is, is that, if you can’t define something, how can you achieve something? Right?

Fries: Yeah.

Shimel: And so, it starts with, “Well, what exactly does digital transformation mean?” And so, I’ll throw it back at you—what does digital transformation mean to you?

Fries: So, digital transformation for us is about helping our clients with the—you know, the doing and the engineering work of doing digital transformation. So, it’s about software development—you know, in particular it’s cloud development today—QA automation, and DevOps. I mean, those are really the big three areas of expertise within the company that we’ve really brought together under the digital transformation sort of heading as well as our agile methodology expertise, and so, bringing kind of those four things together. And they completely make sense together, because, you know, DevOps is really kind of the technology reflection of agile methodology and agile methodology is kind of the methodology reflection of the DevOps technology mindset. And QA automation is so tightly wound into DevOps and really the way that we’re delivering software and the way that our DevOps solutions work are very much married a lot today to cloud development.

And so, we’re bringing all of those things together, which are all things that Exadel had lots of expertise in, but figuring out how to make sure that we were weaving those strands together, if you will, in a really sort of explicit way and building up some solutions for clients. Not just, “Hey, we’re really good at those things, and we have people who can be really good at those things for you,” but we can bring all of our best practices together and some technology solutions together.

So, that’s what it is for us. It’s very much, you know, we’re a software development, software engineering firm, so we really—you know, we’re not sort of going after the cultural transformation part of that, or the, you know, the change management. I mean, we certainly have experience with those things, but for us, it’s really about the development side of it and our expertise in helping clients take on hard projects and succeed.

Shimel: Absolutely, absolutely. Let’s talk a little bit about something new that Exadel recently delivered, and that’s the Innovation Lab. Talk to us—what exactly is the Innovation Lab?

Fries: Yeah, the Innovation Lab is, it’s a new offering that we’re bringing to the market that combines some things that we already have into one thing. So, you know, we’ve all heard about the importance of innovation and even innovation labs. You know, some companies have them or are creating them. Exadel’s Innovation Lab is sort of more of a virtual innovation lab as opposed to, say, a physical place that we help someone create.

So, we already have something called Appery, which is a cross-platform, low code development environment for creating cross-platform mobile apps as well as, like, a low code backend that runs behind that. So, that’s a way to build software very quickly to create real, working software.

We already have a lot of expertise in agile development, as I mentioned before. And so, that’s also part of what we do. We have really great resources, all of those developers that we have, you know, in Europe and some here. And we have some packaged solutions that are a part of those practices.

So, we’re bringing those all together to help our clients innovate. So, you know, what we wanna do is help our clients who are looking for a way to move faster, experiment, try something, get some features in front of customers or business stakeholders more quickly, and the Innovation Lab is our sort of packaged solution for doing that.

So we can, we bring all of those things together—low code development, agile, on-demand resources when there might be something. Since a lot of what people what to experiment today are things like artificial intelligence and blockchain and how can we make those things work for us, so that’s—you know, often, we might have to bring in, you know, we might have to bring in an expert to help out with that as well.

So, it’s really, it’s all of those things to help our customers and new customers innovate more quickly.

Shimel: Got it. So, you know, and to me, when I look at it, Jonathan, you know, we talk about digital transformation, and what I said before about how, if you can’t define it, how can you be successful, and even once you define it, it’s an experiment in a lot of ways, right? It’s kinda that classic DevOps where you deliver, you learn, you get feedback loops, you iterate, you reiterate, and you keep reiterating.

And an innovation lab is kinda the perfect place to kinda have that sort of learning that propels, that helps you define and then succeed in your digital transformation, right?

Fries: Yep.

Shimel: You know, you don’t wanna practice, I guess, on live TV or stuff like that. But you need—you need these labs to push the envelope and find out what works for you and what doesn’t work for you.

Fries: Yeah. I very much view it, you know, as an extension of the product owner, you know, life cycle from scrum. You know, there’s the regular sort of software development life cycle within scrum where you’re doing your sprints and you’re delivering software.

Shimel: Mm-hmm.

Fries: But a big part of what the product owner should be doing is developing the product backlog which includes, you know, testable hypotheses. That’s kinda the way that the scrum community talks about it.

And so, the Innovation Lab is a way for product owners to test some hypotheses that they might not be able to test, you know, if they already have a product. Like, you may not wanna do all the work to develop it and test the hypotheses over here, or that hypothesis over here. You may wanna use something like the Innovation Lab where we can use some of the tools at our disposal to create something that you can deliver and test out one of those—you know, test a hypothesis kind of on its own, if you will—but with working software. Which, you know, as we know is also a big part of agile and DevOps. You know, wireframes and requirements are great and they have a place, but they’re not the best way to show people what you’re doing or get feedback, and this really allows us to help clients do that and do it more quickly.

Shimel: Got it. I agree 100 percent. Interesting—great idea. Moving off Innovation Lab, there’s other stuff going on at Exadel. You wanna share with our audience a little bit?

Fries: Sure, yeah. We just launched the practice areas. As I mentioned, I’m the head of the Digital Transformation practice, and we also have a Digital Marketing Technology practice and a Products and Platforms practice that, much like digital transformation, the other two are also things that, you know, in places where we already have a fair amount of expertise and were kind of collecting all of that together in one place.

So, for Digital Marketing Technology, we have some pretty significant clients for whom we’ve done work with Adobe Experience Manager to build global, localized, large scale websites. And since we had really done that several times, the Digital Marketing Technology practice is all about packaging that solution and delivering that to other clients for kind of building those large scale worldwide type of websites with Adobe.

Products and Platforms is—you know, given that we’ve developed Appery, which really is, you know, it’s not just an application, it’s a whole platform for building other applications, and we’ve done that both for ourselves with Appery as well with several of our other clients like GHX where we’re creating a lot more than just an application, it’s this whole ecosystem. And so, that Products and Platforms practice sort of brings together the best of our knowledge base about developing those really sophisticated, large scale platforms.

And Digital Transformation, of course, which is mine, is all about DevOps, cloud tech, QA automation, and agile. We have a solution that we’re putting together within the Digital Transformation practice that is a cross-cloud Kubernetes implementation that’s all done with Terraform and we’re actually getting ready to use that with the first customer now. We’ve kinda been just doing our internal dev on it, but we’ve shown it to some people and they’re pretty interested in that. The first customer will probably just use it on Azure, but it’s got some really sophisticated—you know, deploying Kubernetes with Terraform, autoscaling, a lot of really cool tech for containerized application development. So, I’m pretty excited about that.

Shimel: So am I. I mean, it’s an exciting time to be alive in IT. I mean, from a developer point of view, from an ops point of view, there are so many options and so—you know, such power at your fingertips.

Fries: Yeah.

Shimel: It really is, you know, it’s a golden age to be into this kinda stuff.

Fries: Yeah, I agree. I mean, I just—I think it’s an amazing time and, you know, I think there’s so much opportunity. There’s so much opportunity out there in what you can do and so forth and then how easy it is now to, you know, to bring computing solutions online for stuff, you know, and it’s what can be done.

It’s awesome, and I know that, you know, it’s a lot of change and it can be hard on people sometimes, but I’m definitely an optimist and an “all ships will rise” type of guy, so, you know, I see all those opportunities out there and it’s like—you know, yeah, there’s an awful lot exciting going on.

Shimel: Well, you know, Jonathan, I think in our business, either we can be optimists, or we can be cynics.

Fries: Yeah.

Shimel: I got into it yesterday, some guy, I don’t even remember his name, but he tweeted, “Oh, those DevOps people selling snake oil! There’s no such thing!” I think they reach a certain age where they just feel like there’s nothing new under the sun, and therefore, they’re just gonna bad mouth, right, whatever new comes along, and—hey man, you know, there’s a place for them on Earth, too, I guess.

Fries: Yeah, and I mean, I think there’s always, I think, a real reason to be concerned about automation and the changes that that brings to not just our industry, but all of society. I mean, you can look around and see how much automation is impacting everything and, you know, as somebody with—you know, I have kids who are grade school aged kids, and it’s like, the world’s gonna look a lot different 20 years from now, so here’s what you need to spend your time thinking about and learning. Because, you know, if you really wanna do this kinda job, it’s not gonna be there 20 years from now.

Shimel: And I have kids in high school and college and I’m telling them the same thing, man. It’s a crazy world. But you know something? To me, you know, we talk about being optimist, pessimist—Jonathan, the flip side of digital transformation is disruption.

Fries: Yeah.

Shimel: Right? And so, you get to the haves and the have nots. You have the empowered people who embrace transformation and are accelerating their business, and you have the laggards who don’t, and they may very well have to die off, right?

Fries: Yeah.

Shimel: I think that’s the choice that we—you know, that it’s nice to talk about this golden age, but that’s also the choice out there is, you can get with it or fall by the wayside. It’s compete or die. And, you know, that may be harsh to some, but that, I think, is the way it is.

Fries: Yeah. It’s kind of been true for, you know, for a while, honestly. Industrialization automated some things, and like I said, I think, at the end of the day, the new businesses that will be created by digital transformation, the businesses that will be completely transformed by digital transformation will create, you know, even more opportunity, and as long as you are looking at it through the lens of those things, even though automation can be—you know, it can be scary.

I mean, like I said, I came from—I was a developer and worked in IT and things like that, and you know, there was lots of things even 20 years ago, where it’s like, “Oh, these things are gonna change everything and jobs will go away” and it’s like—you know, that’s—

Shimel: [Cross talk] Doesn’t happen, doesn’t happen. Anyway, Jonathan—

Fries: No, it happens.

Shimel: – when we started, I told you, the 15 minutes goes really quick, man. [Laughter]

Fries: Yeah.

Shimel: And we’re way over already. I apologize, but I didn’t wanna stop you, you were on a roll, and I thought it was a good conversation. So, but we’re gonna need to pull the plug on this episode of DevOps Chat. Jonathan Fries from Exadel, thanks for being our guest today.

Fries: Absolutely, Alan. It was great. Thanks for having me.

Shimel: Alright! This is Alan Shimel, devopsy.kinsta.cloud, and you just listened to another DevOps Chat.

— Alan Shimel

April 26, 2019
DevOps Chat: Performance Testing with SmartBear’s Keshav Vasudevan

In this DevOps Chat we speak with Keshav Vasudevan, product manager for performance testing at SmartBear. Keshav talks about the move to “end-to-end DevOps,” the importance of shifting left with testing and the latest state-of-the-art in performance and load testing with SmartBear.

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

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Joining me in this DevOps Chat is Keshav Vasudevan – and I’m sure I mispronounced that; we’ll let him correct it. Keshav is with SmartBear and he’s our guest in this DevOps Chat. Keshav, welcome.

Keshav Vasudevan: Hey, thanks, Alan. So happy to be here and, yeah, I will correct it – it’s actually Keshav Vasudevan, so that’s how you say my last name. And I’m – I currently work at the –

Shimel: Vasudevan, okay.

Vasudevan: Yeah. I work –

Shimel: I’m glad you _____ –

Vasudevan: Uh-huh?

Shimel: Well, give us your – okay, so – and we’ll call you Keshav for the rest of the podcast today. But, Keshav, you’re with SmartBear, but why don’t you give our audience a little background? What’s your own personal journey here?

Vasudevan: Oh, of course. I mean, personally, I’m coming from an engineering background. Yeah, I love all things code. I love building applications and, in my spare time, I just love building mobile apps and Web-based apps as just hobby projects, which is why it felt like a natural fit to be at SmartBear Software. I’m incredibly passionate about quality as a whole and I understand and know the importance of having consistent quality to ensure the best optimal end-user experience.

So, at SmartBear, currently, I’m the product manager for performance testing and specifically in the LoadNinja application. And I help communicate the value of shift-left testing in the Agile- and DevOps-based ecosystems that typically we’re seeing the world shift towards. And, of course, I’m responsible for the product management and execution of our innovative, new, revolutionary platform in the performance-testing space, essentially allowing people to do real browser-based load testing at scale, which is unprecedented so far.

Shimel: Very cool. So, Keshav, you’re right in the heart of it of what SmartBear’s about, but SmartBear is a company – you know, when we look at the DevOps space, the move is obviously towards “bigger is better.” We have all these companies who are trying to do end-to-end DevOps and complete-life-cycle DevOps. SmartBear is a company that, for as long as I’m familiar with them, have had multiple products and plays – you know, I’m not saying you’re end-to-end DevOps or that’s what you aspire to be at SmartBear, but SmartBear is definitely a company where you aren’t singular product, singularly product-focused on any one area. SmartBear – you know, there was a lot of testing products, but there was a lot of other products too.

And, recently – well, historically, each of those products almost had their own identity, as they should, but the SmartBear moniker was almost secondary to the individual products. And, recently, we’ve seen that change, right? Where SmartBear has made a broader effort to bring all of these disparate products into a cohesive type of vision of going to market under “SmartBear.” You wanna elaborate on that a little bit? Or, better yet, give our audience kind of the breadth of all the different solutions SmartBear can help with.

Vasudevan: You bring up a great point, Alan. So SmartBear’s been around for almost ten years now. And, since our inception in 2009, we’ve grown into a global company, which testers and developers and architects and designers have come to trust with their overall software-development needs. Our initial focus, when we first started, was around software collaboration and testing, but, eventually, of course, as the company grew and as we added more talented people to the company and also as we grew in user base, we realized that we could actually solve much more broader functional use cases.

And so, since our inception, we right now have 11 global offices. We are a big advocate of open-source platforms and tools, and so a combination of our open-source tools, which is SoapUI, which is one of the most popular API-based testing tools, and Swagger, which includes, of course, the Swagger UI, the Editor, the Codegen, and the commercial SwaggerHub, are all part of our ecosystem. And so, in total, we have over 6.5 million users and over 22,000 customers of our commercial platforms. And, since we’ve started, we have over 500 employees. So that is history of SmartBear and where we are in its current state, but you’re absolutely right. We have a breadth of different products, that each essentially cater to different aspects of the overall software development life cycle.

And so, if you look at the overall life cycle, we have tools that cater to solving and solving use cases and problems and seeing the design phase of the software journey, the actual development and testing and collaboration aspect, cross-functional and performance testing. We’d integrated a bunch of our partners in the deployment phase, with AWS, for example, or Kubernetes. And, finally, in the actual post-production and post-deployment, we actually have monitoring tools as well. So we essentially play in the entire software development life cycle, and we cater to different audiences and our tools overall cater to different use cases in those journeys.

Now we’ve gotten a lot of good feedback for each of these products, but we also recognize, at the end of the day, that, today’s day and age, Agile and DevOps is the way products – or software-development teams are moving towards. This is primarily, again, because software development has evolved in order to meet the growing demands of consumers. And consumers right now, today’s consumers of software applications, are looking two important things. The first is they want features, right? The switching cost to go from one application to the next is going lower and lower, so, if I, as a consumer, am not getting the best features on a regular basis or new updates or enhancements on a regular basis, I might get frustrated and I might just move to another vendor. And the second thing is we have started to expect a lot of good quality in all the things that we’re consuming because, again, as we’re digital consumers, we know that, every day, we spend over 11 hours in front of our computer and looking through different applications. So we have come to expect a certain standard of quality.

And all of this ideal of fast development and incorporating testing and quality into every aspect of this journey is achieved with the ideal of incorporating Agile and DevOps into your workflow. And so we know that, to go across all of these different functions in a seamless and automated fashion, you have to essentially integrate all of the different tools that we have that cater to all of these individual use cases, in a seamless fashion as well. And so – oh, one other thing that we pride ourselves on is we, from a product level, we have a seamless integration across all of these different verticals, right?

So, for example, we have the ability in the performance-testing space to essentially integrate with Jenkins, with LoadNinja, that essentially now allows you to automate your load testing with real browsers at scale, meaning with 10 virtual users or 10,000 users. You can be rest assured that is the most accurate representation of load. All of this can be integrated and automated using Jenkins with a simple plug-in. Right? And this also then integrates with other tools. For example, we have an integration with our design tool, which is SwaggerHub, with our API-testing tool, which is SoapUI. So then you can essentially easily design your API, architect it easily, design the API, make sure it solves the end-user use cases, and then push it to the tester and developer to actually test out each of these functionalities. So we wanna make sure that this process, this ideal of DevOps, is actually achieved in execution with the seamless integration.

Now one level higher is the actual story and the marketing and the branding around it. And we’re proud to say that SmartBear recently unveiled its new brand that gives our customers and prospects and users a more cohesive understanding of how each of these tools fit together, feel proud of the fact that they’re now part of the SmartBear ecosystem, and allow them to, essentially, seamlessly move from one tool to the next because of maintaining the branding and user experience across each of these tools. And that was a huge undertaking that we did and we just unveiled it last year at our user conference, Connect. And we’ve gotten lot of, lot of, lot of good feedback about our new brand, our logo, and everything else around that. So it’s a long–winded way of saying, “Yes, you’re absolutely right. And we’re making sure that that we are achieving that as well.”

Shimel: Absolutely. And you know what? I have one of the shirts with the new logo they sent me too, so thanks for that. But, you know, the interesting takeaway here – I hear from so many and I recently received an e-mail from a fellow in the field who said, “Where do you see – we need to be moving to platforms. We need platforms to build on. And how do you build a platform? And where do you see the need for a platform?” And then you look at, as you’ve just laid out here, SmartBear and you take these tools and individual solutions, point-solutions that you guys had put together over the years, and showing how integration among them, as well as integrating with best-of-breed kinda tools out there, like a Jenkins and some of – and we were blessed in DevOps to have a lot of open-source solutions as well, but integrating with a lot of these open-source. I mean, this is how you stitch together a platform. This is how you get “one plus one equals three.” Right?

Vasudevan: Yes, exactly. Absolutely.

Shimel: Yep. So, Keshav, we’ve waste – we didn’t waste but we’ve spoken an awful lot about kind of background on SmartBear. I really wanted to spend our time talking about what’s new and what’s going on with you and your team there, so why don’t we dig down and peel the onion back a couple layers on that? What do you have – imagine you may – you know, you alluded to it earlier but let’s dig in: what’s happening?

Vasudevan: Absolutely. So one of the things, as I mentioned in my introduction, as something which we as a company are really passionate about, is ensuring quality. Right? And, over the last 15 to 30 years, over the last – well, let’s say over the last 15 years, we as users – and when I say “users,” anyone – me, you, our friend; it’s essentially consumers of applications – have started to expect a certain level of quality. And this is how software development has evolved, in order to meet this demand.

And, as we have touched upon, this is why Agile has evolved, which is essentially moving fast, allowing developers and engineers to build features in a much more faster way and deploy them seamlessly so that the end users get them in the quickest way possible. Right? And we’re always listening to the end-user feedback and updating the platform. Then there’s DevOps, right? Which is, again, trying to follow the same ideal and essentially having a much more collaborative approach towards testing, operations, and development together.

Now let’s go dissect quality, the testing aspect of it. Right? So Agile, to allow for Agile- and DevOps-based testing, functional testing tools have done a great job of keeping up with the times. Right? For example, we have two tools like that, which is SoapUI and TestComplete. And they’ve done a phenomenal job in terms of allowing people to quickly come in and create their test scripts, make sure it all works, make sure to write the test cases really quickly because they have features to do that, and then, again, automate the entire process, using maybe a REST API or, of course, using an existing CI/CD tool.

Performance testing, though, which is a huge – which is a big business KPI in today’s day and age, right, is something that people are still, to this day, scared to do. We talk to product teams and engineering teams on a daily basis, who tell us how important they know performance testing is. For example, we know that, if consumers take more than – if it takes more then 3 seconds for a certain e-commerce page to load, for a customer, they’ll leave. They’ll just go to another platform. The switching costs are getting lower and lower and people are getting more impatient, so, if it’s gonna take a while to do a certain transaction, people will leave. And that is a huge business loss at scale for your company, for your platform, and as an organization as a whole.

So product and engineering teams, Agile teams, want to do performance testing. However, performance testing, to this day, has not evolved to keep up with the growing needs of Agile and DevOps-based workflows. To this day, it takes such a long time, for me as a performance tester, to create a test script. I have to essentially learn – and, if I was a developer or functional tester wanting to do performance testing, I have to forget about it. I have to hire a consultant because my learning curve is gonna be so steep. I have to allocate a lot of time in my day-to-day operation in order to create a simple test script. This is because, over the last 30 years of performance testing, the technological process has not evolved at all. To this day, if you’re creating a performance test script, you have to record all the transactions between the browser and the server. You’re doing this under the protocol level. That is typically how you actually create a performance test script.

Now, as you know, the responses and the requests between server and client will have certain dynamic characteristics, like session IDs, cookies, and so on. So, in order to play this back across 1 user or 10,000 users to do the performance testing, you will have to do this programming and dynamic correlation. This process takes anywhere between several hours to a few days to even become successful, for the most basic transactions. Now imagine doing this for the complex applications that we have today, some of the AJAX applications which are very client-rich, in terms of actions and allowing users to do multiple things. The effort that is involved to do this multiplies threefold. Right?

And so this is why performance testing is still, to this day, seen as something which no one wants to touch. They’ll hire a consultant; they’ll have a centralized function to do this. Then there’s, of course, the actual process of emulating and creating the load itself because, to this day, we still use emulators to generate the load, which is not necessarily representative of the end-user experience.

So this is something we saw over the last one year and we decided to do something about it, which is what – you know, our engineers came together. We said, “We are passionate about this. We face this issue ourselves. Let’s do something about it.” And so, essentially, we productized a new approach to doing load testing, essentially allowing users or testers or developers or functional testers – anyone who’s passionate about performance testing, anyone who’s behind an application, be it a marketer, a product manager, a functional tester, or a performance tester – to essentially come in, record, and instantly play back the transactions that they record in the test script, without doing any programming or dynamic correlation whatsoever. Right?

And, from here, of course, you can – and take the script that you have and spin up tens of thousands of real browsers to go ahead and do the load test, based on these transactions. Right? This is a – I don’t use the word lightly here, but a revolutionary approach to actually doing performance testing because this is unprecedented, to essentially create browser-based test scripts without doing any sort of protocol-based recording, which allows you then to create test scripts out of the box. And then simulate tens of thousands of real browsers to run these scripts on them. So, as a user, as a tester, you’re, one, going to save over 50 to 70 percent of your time, doing the actual load testing, because the scripting process has become so much more easier. And you’re gonna get results that are coming straight from the browser, so you can be rest assured that this is the most accurate and realistic representation of the performances that your application will be showing for end users. And this is what LoadNinja is, as a product.

And, over the last five months, since we launched in October, end of October, during our user conference, we’ve seen tremendous traction in the market. We’ve seen so many customers come to us, sign up for annuals and partner with us, to essentially allow them to do load testing. And it’s just phenomenal, as a product manager, and it’s like seeing the vision come to fruition and actually seeing the people who are behind products – product managers, functional testers, all of them – coming and saying, “Hey, we can now do performance testing by ourselves, without necessarily having to get a certification with an expensive tool. Without having to spend so much more money and dollars trying to get a consultant.” They can do this all by themselves and that’s the most gratifying thing I ever heard. So, yeah. So there’s a lot happening, but the LoadNinja’s primarily something that we’re super proud of, as a company. It was built in house by us. The revolutionary technology to do this it’s something which performance testing has never seen to this day.

Shimel: You know, listening to you, all I can think of is back to my own days as a entrepreneur and developing security solutions, and we’d have to go get performance testing done. We were selling to DOD – it was large, large networks – and this is pre-DevOps, obviously, and pre-automation and pre-continuous. And, my god, the budget for the performance testing was bigger than the budget for the development team. It was nuts. I mean, it was – so, when I hear now about how this stuff is being done in the cloud and “automated” and “scalable” and the price points, it’s just crazy.

Vasudevan: It is. It is. We’ve come a long way. And, to this day, there’s still – performance testing is seen as a monolithic and centralized function, right? And so, to this day, what you saw years ago, many of the factors are still there. So, yeah. So you’re absolutely right and it’s good to see the cloud coming in, but as a performance-testing industry and tool vendors, we can do a lot more to push the boundaries and keep up with the growing demands of engineering and quality as a whole.

Shimel: Yep. Got it. Got it. You know, Keshav, I told you when we started things get out of control. We were supposed to go 15; we’re at 20 minutes.

Vasudevan: [Chuckles]

Shimel: We’ll have to continue our SmartBear discussion on another DevOps Chat, at another date. We’ll have you back on soon. But why don’t we put an end for it right here? But, before we do, people listening, they like what they heard; they’re interested. Where can they go get more information?

Vasudevan: Oh, absolutely. So the best place to go is loadninja.com, so L-O-A-D-N-I-N-J-A-dot-com. And you should have all the required information to become successful and get started. One of the things we pride ourselves, as a product and engineering team, is our turnaround for new features and enhancements. We deploy almost every week and, again, using the – many of the learnings, we learned from your website, Alan, in the DevOps world, to essentially continuously integrate and deploy every now and then, every week, in order to get the features and enhancements that users require. So go to loadninja.com; you’ll have all the required information to become successful.

Shimel: Fantastic. Thank you very much for being a guest on this DevOps Chat. And I am serious – we’ll have to have you back on here – but, for now, I think we’re gonna pull the plug on this episode. Thanks, everyone, for listening. This is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard, Container Journal, Digital Anarchist. You’ve just listened to another DevOps Chat. Have a great day, everyone.

— Alan Shimel

April 19, 2019
DevOps Chat: Aqua Security Talks Funding, Security in a Cloud-Native World

Aqua Security, one of the leaders in container and cloud-native security, recently announced it has raised $62 million in a “C” round of investment, led by Insight Partners.

In this DevOps Chat, we speak with Rani Osnat and Andy Feit of Aqua Security about how this validates the cloud-native security field that Aqua has helped develop.

The video of our conversation is immediately below, followed by the transcript of our conversation. An audio version is also available on Soundcloud.

[videopress 1pfe0tRG]

Transcript

Alan Shimel: Hello, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Container Journal, Security Boulevard for MediaOps and I’m really happy to be joined by my friends from Aqua Security. Charge of product marketing, we’ve got Rani Osnat, and, in charge of go-to-market, Andy –

Andy Feit: Go-to-market, that’s right, Alan.

Shimel: – none other than Andy Feit. Both of these guys are familiar to our audience or you’re both familiar to the audience – you’ve been on – but, guys, first of all, congratulations, mazel tov, whatever you wanna say. Big news today with Aqua. You guys raised a Series C, I believe it is, for $62 million.

Feit: Yeah, thank you, Alan.

Rani Osnat: Thank you, Alan.

Shimel: Congratulations. So let’s talk about what this means, guys. So, first of all, it looks like this round was led by Insight Ventures, correct?

Feit: Yep.

Shimel: And I don’t know if we know; who is the Insight partner kinda leading the charge on this?

Osnat: It’s Jeff Horing, was the _____ –

Shimel: So I know Jeff and he’s one of the senior people there. Will Jeff be joining the board of directors?

Feit: Yeah, so Insight will have a board seat.

Shimel: Okay. Will it be Jeff, though, or you don’t know at this point?

[Crosstalk]

Osnat: Yeah, we’re not sure that it’s gonna be Jeff.

Feit: We’re not positive, yeah.

Shimel: Okay. I don’t mean to ask any trick questions, so don’t worry. So, Andy and Rani, you know, what I thought was interesting in reading the release was, yes, Insight did lead this round for $62 million, but a couple of things to note. Number one, your existing ventures, Lightspeed, Microsoft or M12, M7, whatever they call it –

Osnat: M12, _____.

Shimel: – Shlomo Kramer. You know, your existing venture investors all participated in this, correct?

Osnat: Correct. Yeah.

Shimel: And that says something, right? People believe in it enough to keep writing more dollars into it. Kudos to the Aqua team ’cause that does mean something.

Osnat: Yeah, and it has been like that in all previous rounds as well, so we’ve always had the existing investors continue to participate. And I think, from their perspective, obviously, this is – they’ve taken – especially the early investors, like Shlomo Kramer and then TLV Partners, have taken a risk, investing in a very early-stage startup with an uncertain market. And now a lot of that risk is gone – you know, you can never know, but it’s a much more solid proposition than we had _____ _____ ago –

Shimel: Well, it certainly less risky than a raw startup, but, you know –

Osnat: It’s less risky, and so they deserve it.

Shimel: – from an investment point of view, when they – it’s almost doubling down, when they continue to participate. Right? That’s saying, “I believe in this enough that I don’t wanna be watered down in my stake in the company, and so I’m gonna invest my pro rata or per-capita share so that my stake in the company remains constant, not decreased or watered down as they raise more money.” So it is very significant.

The other thing I just wanted to mention is, hey, this brings the total raised, I think, to $100 million, maybe a little over $100 million.

Feit: Just don’t round down, yeah.

Shimel: I was doing the math on my fingers; I ran out of the toes, but I knew it was close. But the obvious question then becomes “So does this move Aqua into a unicorn, where you have a valuation of a million-plus?”

Feit: Yeah, we’re not really sharing the details on the post-money valuation here. One of the nice things about being a privately-held company: you don’t have to share all those details. But, obviously, the number’s more than $100 million and we’re excited about bringing in a new investor that’s actually more than just bringing money to us. And I think what’s great about Insight is how involved they are, how well they know the space, the introductions they can make to partners as well as end-user customers. And this is really – they are a late-stage investor that knows what it takes to make a company successful.

Shimel: No doubt about it. As we were talking off camera before, I have a relationship with Insight for a number of years now and, look, I’ve seen them invest in many companies that I’m very familiar with – some of them, I’ve worked with. Companies like FireMon and JFrog and Tricentis, Aquanow, and others. So, I mean, their record kinda speaks for itself. And I will tell you, more than just writing a check, I’ve seen firsthand, right, what they’ve done. I mean, frankly, we’ve talked about working with them here at MediaOps, in doing something for their whole portfolio, right? And great company. You couldn’t pick a better partner, in my opinion.

Feit: We definitely feel that way and it’s impressive how well they know the space. Through the due diligence process and even –

Shimel: No doubt about it.

Feit: – here at the meeting, they’re digging in. And the fact that they spoke with our customers, they met with our team, they looked at our product, they went through it – it’s a testament to how far we’ve come and we’re excited about that.

Shimel: Great. So let me pivot now. So, again, congratulations on the raise. That’s a significant amount of money. It means you guys can do some great things. In reading over or perusing the release, though, I saw some other kinda subtle changes in messaging, and that is I knew Aqua or many of us may know Aqua as a container security company. And now I see the messaging changing to more a cloud-native security company. Let’s talk about that. What does that mean, Rani?

Osnat: Yeah, I think, when we started out, the market was different, in terms of adoption and also in terms of the technology landscape. A lot of the technologies that are now maturing were really experimental at the time – and we’re not talking about a long time ago; it’s three and a half years ago – but things like serverless, for example, that are catching on. They’re not as big as containers yet, but, if you believe some of what the proponents say, they will be bigger.

And, in general, I think there’s a trend to look at this cloud-native space, for lack of a better term, as something that is supporting the next generation of application development, application deployment, and runtime environments, where cloud-native doesn’t – it’s not equivalent to cloud, right? I mean, you could run things in the cloud that are not cloud-native and you could run cloud-native applications on-prem as well. But the whole notion is that you support this very Agile, microservices environment that is portable, interoperable, and you can update it very frequently. It’s very resilient – you can update different pieces without impacting other pieces.

And the benefits to enterprises that adopt these technologies are huge, and so that’s why it’s catching on. And we’re at that stage where we see not just the breadth of adoption across the industry, in terms of the number of companies that are actually using it, but also how deep it goes and how wide the adoption is within a given company. So we’re still at an early stage, but we see how a lot of enterprises like banks and insurance companies, not the tech industry itself, are looking at these technologies as strategic to their objectives – digital transformation, customer centricity, all those things.

Shimel: You know, I was telling someone in the office here this morning, “We live in such interesting times if you’re a tech person.” Right? I think bank to my first Web hosting company in 1995 and what it meant to rack up a server.

Osnat: Right.

Shimel: Right? Set up a server for someone. My ops people walked around with tool belts, with pliers and screwdrivers, right, ’cause you had to literally screw in the server into the rack. It’s a different world; it’s an amazing world. Here’s another just something I wanna throw out at you: when we talk about things like serverless and we talk about what Kubernetes brings to the picture, it almost – there’s a place for everyone here. It’s not just the cloud, like we’ve seen with AWS or Azure or Google or Alibaba or – you know, the data center is back.

Osnat: Right. Yeah, I –

Shimel: Right? And there’s now _____ serverless stuff, right?

Osnat: Yeah.

Shimel: And it’s still native.

Osnat: Yeah, absolutely, and we think if you really kinda distill it, from a technology standpoint, to one thing, we’re talking about a complete abstraction of the application layer from the underlying infrastructure. Right? So that’s –

Shimel: That’s it right there. Mm-hmm.

Osnat: – moving into a serverless world, but “serverless” not in a narrow sense of serverless functions that we have today but “serverless” in the wider meaning of the word, where you really don’t have to manage any servers. And any technology that aligns with that concept is legitimately cloud-native and we need to support those technologies.

And, even today, there are many choices, right? You can do everything from running containers on VMs to running containers on bare metal to using container-as-a-service type solutions or serverless containers, like Fargate and ACI, and, of course, serverless functions. And there will be a lot of things in between that. We’re already seeing some technologies that are still very early-stage, like micro-VMs or hybrid container VMs, and this will all have a place because, ultimately, organizations will choose the technology that serves them in the most optimal way, without necessarily being married to one particular technology.

Feit: And I would just add, Alan, I think the common theme between these technologies is the dynamic nature of the infrastructure and the ability to spin up, whether you’re spinning up a VM or requesting a microservice run for 70 milliseconds on a function. It’s happening over the course of the day, over the course of an hour, over the course of minutes. That network is changing and your security infrastructure needs to understand that. And the old-school models of securing these platforms didn’t work before and it’s only getting harder with things like microservices and moving to serverless architectures.

Shimel: No, I agree. I think Rani hit it, actually, right on the head. We’re just seeing this abstraction where that whole infrastructure is so liquid, right, and so dynamic that you almost – you need to secure it, obviously, but the mission of securing the application, irregardless, wherever it’s _____, of the infrastructure, is a mission in and of itself as well.

Feit: Which means you need to understand how _____ _____ _____.

Shimel: And you still have to play nice.

Feit: Yep. Yeah, you need to understand the application part of it, go with it wherever it’s running, and that’s really the magic of what Aqua does.

Osnat: Right.

Shimel: Yeah. Well, and I think that that is the magic, right, and that is the mission. Go with it wherever it’s running. Let me turn back. So, you know, some fresh fuel in the tank. What does the $62 million mean? Let’s talk about it just in terms of go-to-market with you, Andy, but, Rani, let’s talk what does it also mean in terms of product? In this new – I mean, one could say that – saying, “Hey, we’re gonna secure cloud-native. Gives us a bigger surface to play on, a bigger playground to play in.” Go-to-market’s a challenge, right? Both? Let’s hear.

Osnat: Right. Yeah, I mean, so we’ve been – one of our key advantages in this market has been platform support and being able to support different clouds, orchestrators, operating systems, and modalities of cloud-native, right? And, as we see things right now, the market is not – it’s been consolidating around Kubernetes as the orchestration platform, but, at the same time, there are many different flavors and there are different dependencies, on where you’re running, et cetera, that have to be addressed.

So we already are supporting a very large matrix of different technologies and combinations of those technologies. And, as the market continues to hold, we’ll need to continue to track that, so not just support them but actually provide deeper security controls at each level and at each step of the way because we’re not only a container security solution, as you pointed out earlier, but we actually provide this support for various types of cloud-native technologies, various pieces of the stack, and also the full life cycle. So, starting from their early stages of development and CI/CD, going all the way to production environments. And this requires investments in R&D.

Additionally, we also have been investing in open-source tools, specifically around Kubernetes, and we will continue to do that and not only expand the capabilities of those tools that we’ve already put out there in the market but also add new tools. And we do that as part of our philosophy of educating the market, getting out tools that anyone can use, and then, when they get to large production environments, they’ll probably come to us for a commercial solution, with all the benefits of commercial interoperability and support and all that. So that’s – part of the money goes there, obviously.

Feit: And part of the money definitely goes out to build the infrastructure, whether we’re talking sales globally. We’re working with some of the largest customers – companies in the world today and they have a global presence, but, as we go to market and look at growing the business, we have a proven model at this point. I mean, that’s what happens when you get to this late-stage investment. They’re looking for “Do you have customers? Could you do more of them if you had resources in various countries? Could you scale out more by solving more of their problems across divisions and departments in those enterprises and up-sell and cross-sell?”

And then the support infrastructure. One of the things that has really differentiated Aqua, when we win our business – and we’re in a competitive marketplace, but one of the things that really drives us is our ability to be on site with a customer, to support them through their deployment, to be truly invested in their success and integrating with their CI/CD pipelines, integrating with their secrets management, integrating with their SIEM tools. Our solution is not standalone; it’s not a double-click install of a SAS solution. This is part of your entire application development life cycle and it requires resources, so we’ll be – there’ll be people, as part of those organizations, that help ensure the customer deployment is successful.

Shimel: You know, I think Aqua is kinda taking the lead on this cloud-native security. Of course, we all at KubeCon in Seattle a few months ago. There’s another one coming up in Barcelona in – was it May? The end of May, I think.

Feit: May 20th. Believe it, it’s on our schedule.

Shimel: Yeah, no, us too. I think I fly out the 18th. We’ll talk about it. But, you know, I mean, we saw at KubeCon in Seattle this buzz, this palpable excitement – it reminded me of AWS Reinvent five years ago, right? Before the – when the cool kids still there. Where do you think we go? Are we at – I guess, are we at the top of the hype cycle here? Do you think it’s just starting? Where’re we going here?

Feit: It’s still early, I think. [Laughs]

Osnat: It’s not even close to the top. I mean, so KubeCon in Barcelona is gonna be – they’re expecting 10,000 attendees.

Shimel: Wow.

Osnat: Yes.

Shimel: I didn’t realize it’s that big.

Osnat: In Europe, _____ _____ _____ –

Shimel: Yeah, that’s great to hear.

Osnat: – _____ people coming from all over, et cetera. These European events are typically less well-attended than the US equivalents, so the last KubeCon in Seattle, I think, was 8,500, which was about double what Austin was the year before, and now they’re doubling Europe. So that’s, obviously, a very promising sign. But not only that, we see a lot of companies that are new to this space, new to Kubernetes, new to containers, new to serverless. And, sometimes, we get leads on our website – people who’ll purchase – and you can tell they’ve already done their homework, so these are not clueless people who are just kicking the tires, that are trying to learn the basics. They’ve already done that and now they’re actually looking for a solution because they know that they’re going to production, with their environment, in – whatever – six months, three months, nine months.

And so that’s a level of maturity in the market that we didn’t see until recently. And also just the number – I mean, the sheer number of companies that are getting involved is huge and CNCF membership, including end-user organizations, is growing. So all of these are indicators to where it’s going. And I think Andy also wants to say something about our presence at KubeCon.

Feit: Yeah, two things. I would also – before we talk about KubeCon, I think the other indicator is that most of the application workloads that are out there today are still very much in the data center. A lot of them are still monolithic applications; they haven’t all migrated to the cloud or, if they have, maybe they were done with a lift-and-shift. So I think we’re talking about a market that is poised for significantly more growth and we see a lot of different indicators of that. One example is our customers who deployed, say, a pilot project or a handful of applications one or two years ago are now asking us for enterprise-wide licenses and scaling this out to be “This is our cloud-native platform. We’re gonna do everything on this.”

But, at KubeCon this year, in Barcelona, as we did in Seattle, where we did a pre-day event called “KubeSec Enterprise Summit,” we will be doing the same thing in Barcelona. You can register on the CNCF site. When you register for KubeCon, you can sign up for KubeSec Enterprise Summit, which is really an event built just for large-scale enterprise customers rolling out into Kubernetes in production. We’ll have customer speakers; we’ll have an analyst speaker; we’ll have panels. It was a terrific event, very positively reviewed in Seattle, and we’re repeating that now in Barcelona on the 20th of May.

Shimel: That’s great news. You know, and one thing – look, I’m guilty of it; I think you guys are guilty of it too – we call it “KubeCon.” It’s “cloud-native con” too. Right?

Feit: Absolutely. We do tend to – for those of us who’ve been in the market –

Osnat: It’s like for a while.

Feit: Yeah.

Shimel: No, no, I do it. I’m guilty as charged, but I think there’s gonna come a day where cloud-native maybe is bigger than Kube itself, right?

Osnat: Yeah. Well, I think it already is, in a sense, right? I mean, Kubernetes is just – it’s a bit like a fleet. You have a – Kubernetes is the aircraft carrier and then you have everything that surrounds it, the frigates and the destroyers and the minesweepers and all of that.

Shimel: _____ and the battleships. Absolutely.

Osnat: I think that you can tell I play – I used to play _____ –

Shimel: I can tell that. Right.

Feit: And the other thing that I think it comes down to, it’s just harder to say “cloud-native con.”

Osnat: That’s true.

Feit: It’s got too many Cs and Ns and _____ –

Shimel: “KubeCon” does roll. You’re right.

Osnat: Why don’t we call it “KubeCon cloud-native con”? Not “cloud-native con” or “KubeCon.”

Shimel: Absolutely. Hey, guys, I know you’re coming to us from Madrid today. You’re at an Aqua team meeting, and so I appreciate you carving out some time, but I wanna be respectful as well. I know you only had 25, 30 minutes, so. First of all – or last of all, congratulations.

Osnat: Thank you.

Shimel: You and the whole Aqua team. I tend to think of you two as Aqua, but I know there’s more people behind it.

Osnat: I mean, _____ _____ people behind this wall. I don’t _____.

[Laughter]

Shimel: Yeah. But congratulations to both of you. Congratulations to the whole Aqua team. It’s gonna be interesting to see how it plays out. As I said earlier, we live in interesting times in tech, so I will see you both in KubeCon in Madrid? I mean, in Barcelona.

Feit: In Barcelona. And if –

Shimel: In Barcelona. We’re doing videos there for Digital Anarchist, so we’ll have you in and we’ll talk some more.

Feit: I will be at DockerCon before that if you’re going to San Francisco, so _____ –

Shimel: I’m not at DockerCon. I have to go to Iceland. But –

[Crosstalk]

Feit: All right. Great talking to you again, Alan.

Shimel: There’s only so many conferences that I can do, but we try. But we’ll talk more. But, for now, Rani and Andy, congratulations. Continued success with Aqua and we’ll talk to you later.

Feit: Thanks, Alan. Buh-bye, Alan.

Shimel: All right, guys. This is Alan Shimel for devopsy.kinsta.cloud, Container Journal, and Security Boulevard, with our friends from Aqua Security on their recently-announced $62 million raise of round C. Till next time, bye bye.

Osnat: Bye.

Feit: Bye.

— Alan Shimel

April 11, 2019
DevOps Chat: F5’s NGINX Acquisition, with F5’s Lori MacVittie

F5 Networks has acquired NGINX, the leading open source web server player. The move clearly puts F5 in the DevOps space, as well as the open source market.

In this DevOps Chat, we speak with Lori MacVittie of F5 along with Sidney Rabsatt of NGINX. Some great insights into why this acquisition makes sense for both parties.

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, DevOps Chat, and you’re listening to another chat. Today’s chat features two folks from an acquisition announced yesterday. In case you haven’t heard, F5 Networks has acquired NGINX. We’re going to hear more about it from two folks. Number one is our friend, Lori MacVittie from F5 Networks. Lori, welcome. Glad to have you here.

Lori MacVittie: Thanks, happy to be here.

Shimel: Fantastic. Joining Lori and I is Sidney Rabsatt. Sidney is VP of product at NGINX. Correct, Sidney?

Sidney Rabsatt: That’s right, and I’m happy to be here too.

Shimel: Well, everyone’s happy to be here. That’s not a bad thing. Are you happy to be here at the DevOps Chat or are we happy to be here talking about F5’s acquisition of NGINX? Let’s hope it’s both. Lori, give us a little background here. When I saw the deal yesterday. I said, “Wow, that’s a big deal.” I’m not sure – it’s certainly an expansion, up the stack, if you will, for F5.

MacVittie: Up the stack, deeper into the app. It’s all about application delivery. One of the – Sidney mentioned earlier when we were chatting, building on NGINX’s vision, which as I read it, is flawless application delivery. That’s certainly something that F5 has always aspired to achieve as well, but there’s just pieces in the application stack that we don’t play in, or haven’t played in until yesterday with the acquisition. NGINX is the leading webserver. They’ve got an app server. They do some app delivery. They’re very prevalent in many, many places. So we’re very excited to have them on board to see how we can bridge the gap between those two worlds.

Shimel: Absolutely. What about the perspective of NGINX? Money is always nice. Don’t get me wrong. What’s the attraction to F5 here?

Rabsatt: I think there’s at least two sides of it. Working with the folks on this early on, we got to get a sense of the culture of the organization. It felt very compatible. The people we met were great. We had a great time talking, hanging out, sharing ideas. There’s some real optimism about what can be done together. The thing that really gets folks excited, especially on my side of the house, on the NGINX side of the house is the opportunity to do even more faster. We’re a startup. It’s grown to a good size. The set of resources that we have, but looking at F5 and talking to those folks, understanding that they have a shared vision. They see the world very similarly and bringing more resources to bear to execute on the vision that we’re always working towards. It’s something that’s very exciting for us.

Shimel: I can’t disagree with you. I think we’re in violent agreement on it. It is a great opportunity. I guess the next question is how do we integrate, Lori or Sidney, how do we integrate the NGINX webserver, appserver, and the rest of the toolset into the F5 family? Or do we not?

Rabsatt: Do you mind if I take a stab at it?

MacVittie: Go ahead, Sidney, please.

Rabsatt: Sure. Look, I think on the surface of things it might seem as if there’s a ton of integration that needs to happen, and a lot of overlap needs to be addressed, but quite frankly, I’ve been pleased to see how much complementary capabilities we actually have. Oftentimes, in the marketplace, folks will actually deploy both solutions side by side. It’s because we do slightly different things, both super important to folks. When we think about integration, there’s opportunity for F5 customers to be able to leverage NGINX solutions in places where they couldn’t necessarily before. That should be a net benefit to them.

There’s the ability for folks that leverage NGINX solutions to take advantage of things that F5 does, that we don’t particularly do. I think that’s going to be another win for them as well. The integration is really focused on making sure we have the right extensions to the product line identified so we can really give customers the things they need to succeed in delivering those end to end applications, and yes, of course, we’re going to be looking to bring the best of both sets of technologies together in the places where it makes sense, but we’ve been pleased to see it’s not as many overlapping things as we might have found in some situations. We’re very optimistic about the path forward here.

Shimel: So crystallize for me, where do you see things that overlap versus things that play well together? Can you give us some specifics?

Rabsatt: Sure. Things that play well together fall into the category of “Hey, can I bring better scrutiny, better analytics, to the types of solutions that I might already have with NGINX?” On the NGINX side, I’m sorry – on the F5 side, “Hey, can I leverage solutions to give me a little bit more freedom and flexibility to build my apps wherever or however I might choose to?” So I think there’s some goodness there that folks will definitely get access to.

On the integration side, you’ll find most of it is just around making sure that the products work seamlessly together. So to the extent of I have multiple devices in my environment. How do I have a single solution that gives me the ability to manage it the way that I need to? We still need to go through the work of understanding exactly how the different buyers are going to need to interact with the different solutions that we use going forward, but all that work is in progress and again, the overlap tends to be the little stuff. Oh, do you draw a report? Oh yeah, we draw a report. Do you guys do that too? Sure. So how do we bring the best of those technologies together? It’s that kind of thing.

Shimel: Got it. Lori, interested to hear, you heard Sidney here. What do you add to that? What are your feelings on it?

MacVittie: I think he encompassed everything well. We already – you already see both of us in F5 and NGINX together in a lot of environments. From our perspective, I think we’re looking at – one, continuing to invest and amplify the NGINX vision and what they’re trying to execute on, but also where can we add security? Security is a big deal that has to extend from end to end. Right now, that’s a very disjoint process sometimes. That’s why we keep telling security to shift let. I think this is an opportunity that we’re going to be looking for to be able to do those kinds of things and shift that security even lefter with NGINX.

Shimel: Absolutely. It’s funny when you think about security being a driving force behind this acquisition. With NGINX being a webserver, that’s been an area and app server, that’s been an area where security has been required and important forever, even going back to IIS in the day, Internet Information Server and stuff. Here’s an area though I was thinking about. So many people in the public cloud use NGINX as their webserver of choice, whether we’re talking about Amazon or even Microsoft Google or any of them. Lori, does F5 maybe view this acquisition as a way to expand your footprint in public cloud? If so, how?

MacVittie: I don’t think we looked at exactly how that’s going to play out, and what we’re going to do with that. The webserver is something different from the proxy technology that most of our products are built on. So there’s some differences there in how that works. We’re still looking at roadmaps and trying to figure that out. For right now, we’re just going to keep going ahead with both sets of road maps and moving forward. As we continue to explore what we can do together, we’ll figure out where it makes sense.

Shimel: Sidney, same – flip side of that coin – of that question to you around public cloud. Do you see an angle where F5 helps there?

Rabsatt: Yeah, I think F5 already had strong relationships with quite a few of the cloud vendors as do we, and we expect that – we ultimately want to give folks a choice. This all boils down to organizations are trying to build the applications that make sense for them. They want to be able to leverage the best tools and capabilities that help them deliver those applications while giving them the freedom to build the application they want. So whether that is on one cloud, on multicloud, across clouds, and on prem locations, they need that flexibility to do what makes sense for them. A big part of what we’re trying to accomplish here is making sure that F5’s large customer base has the capabilities that NGINX large user base has, which is again, that freedom of flexibility. That means that whether it’s on Amazon Google, Microsoft, any cloud, or any on prem solution, they get to deliver their applications with the security, controls, the visibility that they desire.

Shimel: Excellent. I’m just – in hybrid situation, what about – one of the hottest topics certainly in technology today is the whole Kubernetes container thing. I know both F5 and NGINX had Kubernetes-related solutions and playing in that market. What, if any, does this acquisition, what if anything does this acquisition bring to that? Either one?

Rabsatt: I would say it should be a net benefit. NGINX, there was a recent report I saw. It’s in the public domain. NGINX is the most commonly used ingress controller for Kubernetes environments today. If you think about what Kubernetes means for organizations that are building these modern applications, it’s giving them an environment that allows them to build typically microservices-based applications. So getting those applications exposed to the outside world requires the first thing, the foundational element, the hierarchy of need. It’s getting traffic in and out of that Kubernetes environment. How do you do that? Through the ingress capability.

Our ingress controller is pretty much the number one solution out there for doing that today. That’s the first place people have to start before they get into some of the more complex or exotic things they’d like to be able to do. So our customers, our users are already benefitting from that. It’s allowing them to do what they need to do when it comes to adopting or testing Kubernetes for their own uses.

Shimel: Sure. Lori, even independent of NGINX, what effect is this whole move to Kubernetes and container-ized environment having on F5’s business?

MacVittie: Wow. On the business? Don’t really know. No. There is – we see a lot of customers asking. One, they want guidance on how to do this at scale and safely. A lot of our customers are very concerned about security, about performance. How do they bridge those two worlds, coming out of Kubernetes and trying to get into an environment where there’s a lot more traditional apps and infrastructure still supported? It’s trying to bridge those two worlds.

Our customers are looking at it and they’re bringing it in and they’re adopting it, but they’re also having challenges with the deployment side where NetOps traditionally sit that they don’t have the skills to do the automation. They have problems with integration of the toolsets to build those pipelines. So one of the things that this kind of an acquisition does is bridge that gap. Hopefully we’ll see better integration and easier in and out, both actually in the flow of traffic, but also just between the teams in the businesses, so we think this will help address some of the pains at the people level in organizations by having this end to end delivery chain with both F5 and NGINX.

Shimel: Sure. Sidney, maybe you would know. What are the plans with some sort of common interface or more integration between the two lines?

Rabsatt: I’d say it’s still very early on. We have some good ideas, but we’re not really in a position to preview too much. I will say there’s going to be a focus on again, making sure we’re bringing the best of both solutions together. Again, not nearly as much overlap as you might have expected, or we – I should say as we might have expected. Yeah, what we’re looking at is really the opportunity to bring more features to the things we already have, more so than trying to get rid of things. We’re looking forward to getting this innovation stuff underway. We’ve had some very early conversations, but over the next days and weeks, we’re going to be digging into it very deeply.

Shimel: Makes sense. Lori, so this was as we said right from the outset, what we’re turning to is a move up the application stack. What – is F5 done with that? Will we see more F5 potential either via the acquisition or holistically – organically moving up this stack here in the application world?

MacVittie: I can’t obviously comment on any kind of [laughter] –

Shimel: Can’t tell _____ acquisition is. I get that one.

MacVittie: That’s right. With any company, that’s always a possibility. We have been transforming ourselves in the past year really moving forward with a lot more innovation in terms of exploring things and looking at – we’ve got Aspen mesh going, which is service mesh trying to bring some sanity to Kubernetes inside for scaling. Cloud services, we’ve made a lot of our services as a service. You just hook them up. We’ve been moving deeper into the application stack for a while. This is just going to accelerate that transformation from ADC to application services company.

Shimel: Understood. Understood. Well, guys it really is exciting. One of the things I sit here at devopsy.kinsta.cloud and Security Boulevard and we go to all of the conferences and we cover all the news, and you hear so much “What’s bleeding edge, bleeding edge, bleeding edge?” We tend to forget, or we overlook what are the nuts and bolts, the bread and butter that keeps the internet and these applications going? It is things like the NGINX web server that is the dominant web server in the world today. It is things like the F5 lineup of software and of _____ actually that have been delivering the internet to the public since 2002 or whatever it is. Lori, you probably know, but so it’s good to see innovation continuing to happen. It’s good to see new combinations taking place.

I’m excited to see what comes out of – Sidney, as you said, it’s very early on. It’s a day after the acquisition was announced. Maybe we could check back in six months and see how things are progressing along these lines. In the meantime though, just the usual questions. Everyone from NGINX is staying on? There’s not going to be layoffs as part of the consolidations and stuff, or again too early to tell?

Rabsatt: I mean what we know is F5 is interested in our organization and not just products. They’ve made it very clear they want the vast majority of folks to stay and we expect that to continue to be the case. We look forward to what the future holds together.

Shimel: Yep, understood. Look, I wish you a lot of success, both you guys individually, as well as F5 and NGINX. It’s an exciting combination. Congratulations to both organizations and Lori, I think congratulations on especially to F5 for really making a real great addition to the family there.

MacVittie: Thank you. I know there’s a lot of us. We’re just really excited about this and about the future and what we can do together.

Shimel: Cool, cool, cool. All right, congratulations, guys. We’re going to call it a rap on this edition of DevOps Chat. Lori MacVittie for F5 networks. Sidney Rabsatt for NGINX, soon to be F5 Networks. Thanks for being our guest today on DevOps Chat. Thank you everyone for listening. You’ve just listened to another chat. Bye bye.

— Alan Shimel

April 5, 2019
DevOps Chat: Chef Goes All-In on Open Source

In front of next month’s ChefConf in Seattle, Chef has announced a major refinement to its business model. Affirming and clarifying its commitment to open source business models, Chef will now and in the future release all of its software as open source.

In this DevOps Chat, we speak with Corey Scobie, SVP of Products and Engineering at Chef. He explains that Chef will be adding services, training and support to the open source software, as well as packaging all of this together.

For the full story, be sure to listen to the podcast and check out the video version of this interview below, along with coverage on devopsy.kinsta.cloud.

[videopress nUXwRMxU]

Transcript

Alan Shimel: Hey everyone, It’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to a DevOps Video Chat. Today’s DevOps Video Chat features Corey Scobie, SVP of Engineering, is it?

Corey Scobie: Product and engineering, yep.

Shimel: Product and engineering now at Chef. Hey, Corey, welcome.

Scobie: Thanks, Alan, happy to be here.

Shimel: I’m happy to have you here. Today is a red letter, big day in the history of Chef. You guys are announcing some pretty significant changes to the model is I guess what I would call them. Though, I don’t think the changes are as big as some may initially feel, but let’s go over them. I’m going to let you take the wheel here. Tell our audience.

Scobie: It is a big day today for us at Chef. We are announcing some changes to the way we both produce and ultimately distribute our software, which I think are really exciting. There’s a lot going on in the industry right now. As you probably know, Chef has been one of the marquee players in the open source software development community for some time. Part of the announcement that we’re making today that I think is most exciting, is we’re announcing that what we’re going to do is going forward, produce 100 percent of our product-oriented software in that open source model.

For us, that’s a change because we, over time, and through the addition of additional projects and additional software at Chef, had started following a little bit of an open source, open core path, which means that we had some proprietary software and some open source software, but when we got down to it and we thought about the history of Chef and the roots of what has made Chef such great software in the past, it really came down to collaboration. We realized the best way to make software is to make it in collaboration with the people that actually use the software, at the end of the day.

For us, that’s the big first talking point about the announcement is that we are committed to 100 percent open source software development going forward. We’re committing all of our software to open source repos and GitHub, and then ultimately attaching it and giving it to the commons with the Apache 2.0 license.

Shimel: Sure, so Corey, you know – so you’re talking to someone who has a bit of a history in open source, 20 years. I remember when the whole open core movement first came out. Look, Richard Stallman and that crew, they were really against open core, because they felt it was – it was almost heresy to the whole cathedral and bizarre open source kind of crowd, where if it’s open, it’s open. You can’t be a little bit pregnant. But, nevertheless, we’ve seen companies succeed with this open core or premium, where the core is free and there are premium modules on top of it, but it’s a slippery slope. In all honesty, I think Chef got caught in a little bit with that slippery slope with what’s truly open, what’s free, what is our proprietary that we make money from? I don’t know if the market really got it.

Scobie: Yeah, one of the things that is really tough when you’re following an open core strategy is drawing a very clean line between what is free and what is not free in the world of your technology offerings. For us, that got complicated and then even conflated further as we added more projects to the list. When we opened the InSpec project for security and compliance, when we opened Habitat for application automation, what ended up happening is we had multiple projects that were governed different ways that had different lines between the free and the core part of it. I think ultimately at the end of the day, had I been at Chef during that part of the journey, I probably would have made the same decisions, I’m guessing, but at some point you get back to this reconciliation point where it’s like, “Look. The best thing that you can do for customers if number one, you can collaborate with them, and number two, you can have a really, really clean line between what is free and what is not free in your world.”

For us, it becomes super simple with this announcement. What is free is all of the intellectual property that we’ve contributed to the commons in the world, and will contribute to the commons going forward. What isn’t free is all of the work we do to make a turnkey, enterprise-class, package that enterprise-class customers can pick up and distribute at hyperscale in their organizations, from that point.

Shimel: That brings us to the next thing, and of course this is always the issue. So if you’re going to make all the software and the IP open, well how the heck do you make money?

Scobie: Sure. As it turns out, we’ve got venture capital funding, investors that want to see us turn that into dollars as well. For what it’s worth, we’re feeling pretty good about the shape of the business right now. We just came off the best quarter of revenue we’ve ever had at Chef, prior to this business model, this model change around how we distribute software whatsoever. So we’re feeling really good about the shape of the business, but just the inability to have that simple conversation about what’s free and what isn’t. What we decided was as we’ve matured as a company, and as the space has matured in enterprise automation, what we found is the majority of our customers actually do want to have a very material commercial relationship with us.

Not only do they want the software, but they want the support. They want the content. They want the expertise. They want the warranties and indemnities that go with all of that. So for us, it was very simple. We realized at the end of the day, that the most — that there was a huge constituency of our customers who what they wanted from us was a very curated commercial offering out the other end. So we’ve decided that’s where we’re going to put our effort and our energy, and we’re going to trust in the open source world to fill in the gaps where that isn’t the offering that they want as well.

Shimel: We look at this model, Corey. Obviously, Red Hat’s the poster child for much of the open source world in that most of their software, if not all of it, was in fact open source. It was all in the packaging and the support, and that kind of thing. It sounds very much like that’s going to be the model, or am I wrong?

Scobie: It is – no – there’s a strong analog to what Red Hat has done in the industry as well. What’s interesting is I think that that is the antithesis of what we are seeing from a lot of the more recent moves in the open source industry where there’s a desire to become more proprietary in some cases, or in other cases to try and somehow bend, I think, the definition of what is open source software. For us, the core of it, we get back to the four freedoms, and freedom zero is about the freedom to use the software, but it’s free as in freedom. It’s not free as in dollars.

Shimel: Free as in freedom, or free as in beer, as we used to say, but Corey, to be fair to these companies that are – that we do see going another way, it’s because they didn’t cut it. They tried the Red Hat model, and for whatever reason, they didn’t cut it and they had too much pressure from their boards and the VCs and investors, and so forth. So they tried to take a path that was quicker to money. I’m not here to judge anybody’s – as someone in the Godfather once said, “Far be it from me to disparage what someone does for a living” –

Scobie: I hold the same opinion, Alan, by the way. I sit in judgment of nobody on the decisions that they make about what’s right for their business. I just know that for us, what’s right is to try and both honor the open source roots that we came from, and to also serve the commercial customers that were really knocking at the door and saying, “Look, this is what we want from you. We want even more engagement. We want even more value out of your commercial subscription.”

Shimel: Agreed. Before we jump into the next part of it, which is how it manifests itself within the Chef universe, I wanted to just tie a knot on this one, and mention that when we talk about this model, and you said, “Oh, we’re going to count on the open source community to fill in the gaps,” and one might say, “Well, what are those gaps? I think people have to realize what made Red Hat great was not just distributing Linux. It was that RHEL, and Fedora even before that. It was that package, that distro, that had everything you needed and wanted in there in a really easy to use – you didn’t want for anything else. It was all right there, nicely done for you, instead of running out and having to download different packages and distros from all over the internet, which is what held back Linux on the desktop for so many years. There wasn’t that one package that you could do that.

I think that’s what you’re referring to is Chef’s strategy going forward is to have that killer distro, with all the right packages in it. If you don’t want to pay Chef for that, and I don’t think at this point, though people like software that is free as in beer, and they get free as in freedom with it, no one denies that a company should be able to make a living, that a company should be able to make a profit, pay its employers, pay its developers, and go forward. So for people who either don’t have the money, or don’t have the inclination to buy the packaged product, they can get the open source components, and the community can work on giving you the glue, in essence, that puts these all together. Correct?

Scobie: Absolutely, for sure. Santos came out of that exact scenarios. The scientific community needed something that wasn’t going to be necessarily nearly as curated as Red Hat and Linux was, but they needed a platform for scientific computing, so CentOS was born and has a place in that world. I think our vision for that is exactly the same. If there’s a downstream project that is born of Chef InSpec or Habitat, we welcome it into the community, and we look forward to whatever innovations they bring, and we want to collaborate with anybody that wants to come and take that work out of the commons and create the derivative work out of it, that allows them to meet whatever their goals are. That is the freedom in free and open source software.

Shimel: Absolutely. I think one of the other things though, Corey, is when we look at Chef over the last couple years, we’ve seen the whole InSpec line of security functionality, and we’ve seen Habitat. Look, Habitat was an ambitious piece of – well, it was more than a piece of software. Habitat was an ambitious play, but because there was so many balls in the air and going off in different directions and open/closed, proprietary/not, people never – it wasn’t explained well enough to people. I spent the time at ChefConf so I understood Habitat well, but there’s maybe a thousand people at a Chef conference as opposed to millions of people in the world. I think it was really hard getting InSpec and Habitat, carving out their niche in the world, amidst this whole confusion around the closed/open, supported/paid for, free/not free.

Scobie: Yeah, that’s fair, and I think this really helps us simplify the messaging around that too. I will openly admit I think InSpec is an easier basic value proposition to parse, which is “Look, I need security and compliance in my organization and the right way to do that is express it as code”, so that should be fairly straightforward, and relatively noncontroversial. I think, with respect, to Habitat, what is interesting about Habitat is I agree with you, super ambitious project right from the get-go to redefine the abstraction of packaging and orchestrating the delivery of software in the world.

That’s – it’s huge that there’s a huge surface area associated with that. I think what’s interesting is that we’ve learned much – we’ve learned a lot over the last couple of years about how to help people in the mental journey of how to think about Habitat in the world, and how it relates to Chef, and having that foundation of understanding and knowing Chef, which tens of thousands, if not hundreds of thousands of people already have, the ability for them to jump to where Habitat plays becomes much easier in the world where we can talk about them collaterally and not independently of one another.

Shimel: Fair enough. I think that’s a great segue, Corey, to the next part of our conversation I wanted to have with you, and that is okay, how does this manifest itself down the line of Chef product and services? So we’re going to put all our IP out as open. I guess we should mention also, I think everything is being released under an Apache 2.0 license.

Scobie: That’s correct. Apache 2.0.

Shimel: Industry standard, GPL, Apache are probably the two biggest. How does this manifest itself? What changes does this mean for Chef’s products?

Scobie: On flag day when we release new products with new packaging and new terms and conditions, it’s an evolution that we’ve been going through for some time now, which is really to understand what the interface parts are between the three core engines that we have. So we’ve created an engine for infrastructure automation, which is the Chef project, and going forward, just from a purely – from a branding simplicity perspective, it’s going to be known as Chef Infra, which is I think is fairly straightforward.

Shimel: I’m sorry. Can you repeat that though? Chef…?

Scobie: Infra, as in infrastructure.

Shimel: I-N-F-R-A. Okay.

Scobie: Yeah, and then we’re going to have Chef InSpec, for security and compliance, and the state relationship between infrastructure and security and compliance are pretty – it’s pretty intuitive, which is that if I deploy an operating system, and I want it to be locked down in a certain way and secure and meet a certain set of compliance standards, then testing that on a continuous basis, managing the drift, and being able to automatically remediate any drift that’s happening there seems like a really obvious relationship. What’s interesting though is the relationship between infrastructure and application automation. This is where things get really murky, even for longtime Chef customers who have been wildly successful in using Chef as an infrastructure automation tool. If you go and talk to those customers, what you’ll find is that they’re doing about – 30 percent of what they’re doing is about infrastructure deployment provisioning and shaping, locking down configuration management.

70 percent of what they’re doing is deploying software on top of the operating systems in service of some application that’s going to come along at some point in time and need that – those software dependencies to be there. What we discovered, and this is really the genesis of Habitat, which I’m not even sure – we knew that what was happening in the space of Chef was not working at scale for us. That’s the reason that some folks at Chef went off and decided to create Habitat, but what we didn’t realize is why it wasn’t working as it was at the time. The reason is that there is a natural boundary for building systems from the bottom up in a layer cake approach. It doesn’t matter whether it’s Chef or Antival or Puppet or Kubernetes clusters or whatever, that there is a natural boundary layer, if what you’re doing is building systems from the bottom up.

So you have an operating system, and then you have system libraries, and then you have packages, and then you have middleware, and eventually you have an application. At some point that dependencies graph, the modularity of everything that you lay down, and the dependencies graph gets so complicated that there’s no possibly way you can manage understanding what the implication of changing component X is on all the other components that rely on X. So the beauty of Habitat and where Infrastructure, and where Chef and Habitat come together is that Habitat takes the exact approach. It says, “Look, what you should do is you should define an application, all of the application’s dependencies and all of the orchestration steps for that application to run successfully in any environment regardless of where it is.”

So by doing that, and by removing that layers – that bottoms up layers dependency, what we’ve really done is created an application stack, an enterprise automation stack is what we’re calling it where infrastructure and application automation marry together at a very, very clean abstraction level. The abstraction level is essentially, if you’re running software on the operating system that runs above the kernel, it should be defined by application packages and orchestration, and not by infrastructure packages and orchestration. Now, it’s architecturally it all makes sense, and it actually works really well in practice. Where it’s complicated is that organizationally, INO – traditional INO operators and other infrastructure groups have been tasked with more and more software deployment on top of their stacks. So this is a very paradigm-shifting idea. I think what is helpful for us is the enterprise automation stack allows us to create a framework and a template for how to do that in a way that helps customers adopt that methodology much, much quicker.

Shimel: Fair, fair. So we got Chef Infra. We have Chef InSpec.

Scobie: Yes, and Chef Habitat, Chef Habitat.

Shimel: Chef Habitat sits – I wouldn’t say it sits on top of them.

Scobie: Look, the stack is – we have trouble with this with our marketecture diagrams. If, what happens in the podcast now is you’ll throw up the marketecture diagram you’ll have, what you’ll see is a linear stack, but the state relationship between those three things is much more complex than can be defined in a diagram like that.

Shimel: _____ diagram, sure.

Scobie: Then on top of that, then there’s two other pieces to the portfolio. So we have Chef Automate, which is the observability layer on the top. Of course, if you have automation on all of these things, you want to be able to see across all of your pipelines, across all of your applications, across all of your systems. What is the state of everything that’s running? How has it been deployed? Is it in compliance or not in compliance, etcetera? So we’ve got this whole enterprise dashboard with automation up top. Then on the bottom end of the stack is we need to make it easier for developers to get started. So all of these engines are representative of either infrastructure compliance or application automation as code. What do you do as a developer? You download a bunch of tools. You get started writing code that are the artifacts that actually drive that automation. So Chef Workstation is the compilation of all of those tools and an easy way to set up your development environment to get going. That’s the entirety of the enterprise automation stack. It’s Chef Workstation, Chef Infrastructure – Chef Infra, Chef InSpec, Chef Habitat, and Chef Automate on top.

Shimel: And repeat for me, what all of these packaged together is the –

Scobie: Yeah, the Chef Enterprise Automation Stack.

Shimel: That’s the whole enchilada, so to speak. This is all packaged up into one coherent type of product, if we can call it that. Fair?

Scobie: Exactly. Yeah, one coherent distribution, absolutely.

Shimel: Corey, you know the news broke today around this. Some are saying, “Well, Chef is pivoting. Chef is this.” How do you view this? How do you and the other folks at Chef view this? Is this really a pivot? To me, it’s – I don’t see it as a pivot.

Scobie: Yeah, it’s not a pivot. I mean, first of all, I don’t think it’s – we’ve – you can question the effectiveness or the efficacy of our open source strategy in the past as we’ve meandered through different phases of that, but this is us staying true to the fact that we are an open source company, and so I think we’re leaning into the business model by which Chef was founded, and by which we’ve been operating for quite a while.

Shimel: I agree with you.

Scobie: I think from a technology perspective, we just have more clarity now in how to deliver the components and technology that have become critical to customers who are trying to solve large-scale enterprise automation problems. I don’t know that I would really describe it as a pivot. I think what we’re trying to do is use this as an opportunity to reintroduce people to Chef who maybe haven’t heard of the latest of our innovation in InSpec and Habitat, as an example, who maybe are not familiar with the work that we’ve been doing in the last three or four years. For us, it’s a little bit of a rebirth, but I wouldn’t call it a pivot.

Shimel: I don’t know if I’d call it a rebirth. So here, look, you’re in the forest.

Scobie: I am in the forest. There’s no question.

Shimel: [laughter] I’m outside the forest. To me, obviously a pretty – I’m more than a casual observer. To me, Chef was always an open source company.

Scobie: Always.

Shimel: I think in some ways, what we’ve seen with Chef over the last five years, I would characterize as growing pains for an open source company trying to come to grips with remaining true to its open source roots, while at the same time recognizing you took other people’s money, and that’s how – I lived that life for 20 years. You take other people’s money, they want – it’s a funny thing. They want to get a return on their investment. It’s like trying to serve two masters. It’s a hard – it’s a hard –

Scobie: Not only that, but look, the successful commercialization of any open source project or software company is how you actually create sustainable good in that community for the long-term. Obviously, you need participation from the community, but you also have to inject capital into that community if you want sustained innovation.

Shimel: You have to extract revenue as well though. That’s where I think it gets dicey. So when I look at InSpec and Habitat, I almost feel at some level, they were somewhat hobbled by having to live in this schizophrenic, open/not open, making money/not making money. Well, if it’s totally open, we’re not making money. How much do we put into this? There was just too much of this all over the place, where to me, this is just a clarification. Look, Chef is and will remain an open source company, and our value to our investors is that No. 1, we have this tremendous community around us who are users of our software as well as contributors to the community, but No. 2, we are now offering a proprietary, a for-profit solution that takes the best of this and packages it up nicely.

Scobie: Absolutely. Look, Alan, you make a great point. I would love to give a shout out to the community, because the Chef community is absolutely amazing. I know you’ve been to ChefConf. It’s an experience in and of itself. It’s hard to think of another tech conference that is as authentic and as welcoming and as diverse as ChefConf is, and it’s a bunch of people that come together every year, because they are passionate about solving the challenges of infrastructure management at scale, and application deployment at scale, and all of those things that Chef is interested in as well. So the community is a really key factor of it, but to your point is that there’s just this growing demand in the enterprise. We are the experts in figuring out how to do that in a really, really tight curated way. Of course, we’re going to take advantage of that market opportunity as well.

Shimel: Sure, we got the news out. Is there any part of the news we’re missing, Corey?

Scobie: No, I don’t think so. That really covers the announcements for today. I think the only other thing is we’ve got ChefConf 2019 coming up in Seattle May 20^th – 23^rd in Seattle. It’s going to be a great event. We also have a ChefConf for the first time ever, ChefConf coming to London at the end of June. It’s June 19^th and 20^th, I believe are the dates in London.

Shimel: Really?

Scobie: Yeah.

Shimel: You know I’ll be in London those dates. I’ll have to talk to you about it.

Scobie: Yeah, absolutely. We’d love to see you there, and we’d love to see others there as well. Yeah, so we’ve got a couple big events coming up where we’re going to showcase the latest of the innovation that we’ve had on all of the fronts, innovation, compliance, application automation, our enterprise consoles, all of that kind of stuff. so those are going to be fantastic events coming up. So other than that, we’re looking – we’re really looking forward to getting back to those community roots and really everybody being there together in the trenches together building the next generation of what this is all going to be.

Shimel: Cool. So now let me ask you a question. Put on your wizard’s hat. If we’re talking about ChefConf 2020 now, a year from now, this strategy, this road has been – this strategy has been implemented now. We’re going down this road. How does it manifest itself over the next 12 – 24 months you think?

Scobie: Look, we’ve been talking about that from a product strategy perspective, and I think we’ve got – there’s a lot of opportunity for us to do great work in pulling the pieces of the puzzle together, even more explicitly. We’re doing a lot of work with partners, so I anticipate that the ecosystem partners will be a big player in ChefConf 2020 as well. So we’ve been working with the likes of everybody from Microsoft, Azure DevOps, and the workflows there. We’ve got – we’ve been doing some product work, and continue to do product work with Amazon in the ops work for Chef Automate, managed and hosted to platform there. We’re quite engaged with GitHub because we’re seeing both GitHub and Artifactory and a lot of our customers in the DevOps toolchain and pipeline there. We’re doing some work with that. We’ve been doing a lot of integration with services now. So I actually think that the next phase of this is not just about the Chef parts of the stack, but how those parts of the stack connect with the rest of the ecosystem that is fast emerging in the enterprise automation space as well.

Shimel: Sounds cool. Well, Corey, we’re about out of time. I want to thank you for taking time on what’s a crazy busy day for you guys, to brief our audience on this. Congratulations to the whole Chef team. Tell Barry and everyone else, looking forward to ChefConf. Unfortunately, I won’t be at ChefConf in Seattle. I’m in Europe, but we’re going to have a full team there doing video interviews there and everything. John Willis, our partner at Digital Anarchist will be there, and Chris Reilly. So we’ll have plenty of Chef coverage from ChefConf. Like I said, I didn’t even realize the London one. We’ll try to get over there. I think that’s Tech Week in London actually, which is a pretty big week.

Scobie: Yeah, fantastic. Well, thank you so much, Alan. I appreciate you taking the time today as well. Look forward to seeing your colleagues at ChefConf in Seattle, and then hopefully we’ll see you in London in June.

Shimel: Absolutely. Hey, Corey Scobie, SVP Engineering and Product. I got it right.

Scobie: You got it right.

Shimel: You’re talking to us about some news coming out of Chef today, a little bit of a change in how they package stuff, but they’re still an open source company. Corey, thanks very much.

Scobie: Thank you, Alan.

Shimel: Take care. This is Alan Shimel for devopsy.kinsta.cloud, everyone. Have a great day.

— Alan Shimel

April 2, 2019
DevOps Chat: Computing on the Edge, with Swim.ai’s Simon Crosby

Simon Crosby has made a career of technology on the edge. From leading the charge with the Xen hypervisor to microVMs with Bromium and much more in between, Crosby has led some of the most innovative technology developers in the industry.
He is now the CTO of Swim.ai which is literally bringing computing to the edge (almost an anti-cloud). This approach promises some revolutionary capabilities.

If Simon is involved, there is a good chance it will succeed as well. Have a listen to what Simon is all about now.

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

Transcript

Alan Shimel: Hey, everyone this is Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and we’re here for another DevOps Chat. I’m really lucky to be joined by an old friend of mine for this chat, none other than Simon Crosby who is the CTO of a hot company out there called swim.ai. Simon, welcome.

Simon Crosby: Thanks, Alan. It’s great to speak to you again.

Shimel: Thank you. It’s actually my pleasure. Simon, maybe we have some young ones in the audience who maybe aren’t familiar with the one and only Simon Crosby. Why don’t you give folks a little background of how you came to be here today? Little bit of _____ –

Crosby: Well, I was lucky enough to cofound a company called “XenSource,” which built and maintained the open-source Xen hypervisor, which was – so XenSource was bought by Citrix, but then went on to fame because we built Amazon AWS. And then on, from there, I then cofounded a company called “Bromium,” which used micro-virtualization to do security. And that has, funnily enough, turned also into Amazon’s micro-virtualization, which they very recently open-sourced, as well as the micro-virtualization in Azure.

Shimel: So, in many ways, you’ve given birth to so – “given birth to”? – you’ve helped launch so many of the key technologies that are powering the cloud today, right?

Crosby: It’s fun.

Shimel: Yeah. You know, I think a lot of people tend to think hypervisor, VMware, and they forget, really, how important Xen was and still is.

Crosby: Still is. It still has more VMs than any other hypervisor on the planet.

Shimel: Absolutely. And then Bromium too – I mean, Bromium micro-segmentation, micro-perimeterization, whatever you wanna call it, again, was a – I mean, it was really a defining moment, you know? It was a –

Crosby: Yeah. So I –

Shimel: – _____ approach security.

Crosby: So what Bromium does is every single task on the OS, every tab in your browser, we document your residency – its own little micro-VM.

Shimel: Right.

Crosby: And those things are tiny. And so if bad guys show up, it’s _____ _____. That technology has gone into Windows 10. It’s coming out in stages from Microsoft and it’s also available in Azure and in AWS.

Shimel: Fantastic. But enough about that. We’re here to talk about SWIM.AI. And I’m gonna assume that most of our audience, probably, has not heard of SWIM.AI. They may get from the title that it is based on SWIM, but they may or may not even know SWIM. Why don’t you clue us in, Simon?

Crosby: Well, the name is kind of a clue – it’s “software in motion.” We’re focused on the edge – in fact, intelligent edge computing – and so I’m gonna bend your mind a bit with a definition here. We’re all familiar with cloud and cloud computing as a set of abstractions for building stuff, not as a place, right? So, when we think of it, I’d like you to think of edge computing as needing a set of abstractions. And I think the current abstractions we use for cloud don’t apply very well at the edge. So let’s think of edge computing as a new set of abstractions, the ones that we need to deal with the world, which is generating more data than we can ever hope to store. And so what are the abstractions to do intelligent computing on that?

Now, when we talk about edge intelligence, I mean, I guess four things: first of all, self-training and inference; analytics; any form of query – MapReduce, relational graph cap query, or any old other thing that you might wanna throw into data to analyze. And the key challenges with the current paradigms, the cloud world, which has been so tremendously successful, is really three things: REST, stateless computing, and the notion of a database. And all of these things are vital for all of the apps that we know and love today, but they completely screw up everything that you’re trying to do at the edge.

So just think about this way: if I have an event coming of some sensor at the edge and I throw it up to an AWS Lambda thing, which then goes and looks up the old value in a database, does some computation and puts a new value in database, you know, that’s probably taken 100 milliseconds, 50 milliseconds maybe. If I’m running towards the edge in a distributed application, that’s tens of billions of CPU cycles.

Shimel: Okay.

Crosby: And so this notion of forgetting everything, which is really is focused scaling out the cloud, is terrible at the edge. What you want is a STAPLE model. And so STAPLE computation is fundamental in the edge – anybody who’s written a device driver knows this – and distribution is fundamental. Computing on data as it is generated, which means learning on the fly, analyzing on the fly, are fundamental. Okay? So not storing things on disks and pulling it off later because then you’re analyzing past data and you can only reason about the past. And we have to reason about things as they happen and respond in real time.

Shimel: You know, what’s interesting about this to me, Simon, is – so I guess it’s gotta be, what, 2004, 2005, we start really seeing the cloud go mainstream, if you will. And I –

Crosby: 2000 – you know what? AWS is beginning of 2006.

Shimel: Okay. So fair enough.

Crosby: Oh, but Salesforce, obviously, is a long time ago, but there you go.

Shimel: Yeah, but, you know, this thing “the cloud,” right, and how it kind of exploded on the scene. And your company sort of started in ASP, back in the late ’90s – it was hosting Lotus Notes before there were hypervisors and clouds and _____ bandwidth. But, anyway, part and parcel of the cloud, though, was this notion that there would be this centralized – if not, but it would be distributed – sort of center where certain computation and hosting, like database, et cetera, would – and storage – would happen at that nebulous cloud. But there was always supposed to be the other piece of it, the edge. Right? There was the cloud and the edge. And we got so enamored with the cloud and so much happened with AWS and Azure and Google and a million other clouds out there, hybrid and all privates, we forgot about the edge for about –

Crosby: Well, I think –

I mean, I wanna be a little bit generous here. I think job one was to get enterprise IT out of bring in IT. In other words, get out of running exchange _____ _____ use things like Boomawipe because, gosh, let them run – let somebody else run their stuff for you. It’s not mission-critical. So the trillion dollars of traditional enterprise IT needs to get pushed to the cloud, and that’s happening at a huge pace today, and you see the winners emerging there. But there’s another trend which is happening and that is that, well, if you look at ARM, you know, ARM is licensing 20 billion cores a year.

Shimel: Wow.

Crosby: That’s a big number of CPUs. And every one of those is gonna be connected and generating data. And so that is a trend which is caught up. It’s because everything is smart now, right? You can embed these cores in anything. And so, when you deal with a world which has got that much data coming out of it, we have to do something other than simply save everything in a big data store and think about it later because there will never be a later. There is so much data coming out. And so there is a fundamental requirement that we process this data on the fly. I wanna introduce you a slightly mind-twisting thought. There is going to be so much data that things have to write their own programs. There aren’t enough humans to write programs for the things, right?

Shimel: Yeah, no, I agree.

Crosby: The things generating data will learn experientially, a little bit like you do – okay, you form a hypothesis about the world; you see the way the world develops; and then you change your hypothesis – so things will do that and they will learn on their own data. And, in “learning,” what I mean is you might – they’re writing a program, effectively, these things, right? So the program might be the wait of a DNN or something, and you might not understand what it means, but, when they have absorbed enough data, they’re really good at understanding their world and predicting the way it will evolve around. And that’s the way the world is going, that things write their own programs.

Shimel: You know, I had a conversation with a guy named Luke Kiely, about two or three years ago. Luke was the founder and CEO, at the time, of Puppet. And he had a similar thing – he said, “Alan, it may not be this year, next year, five years or maybe even 10 years or more, but there will come a time where the software needs to write its own software.”

Crosby: Yeah.

Shimel: But, you know, it just – the humans are the bottleneck. Right? The human is the resource constraint.

Crosby: Well, actually, I mean, they’re – we’re on DevOps podcast, but, you know, there will never be DevOps for my younger _____ _____ _____ _____. I’m telling you, there just will never be that. There aren’t enough people to do this, right? And so we have to back up –

Shimel: Go ahead. No, no, you go on ’cause I agree with you. I mean, the _____ – I mean, the human is the single – just like in security, a lot of times, it was – that was the problem. [Chuckles]

Crosby: Yep. No, that’s right. And so more automation is key. By the way, there’s another skillset which I think is hypothesized too much, and that is data science. I mean, programmers are rare, good programmers rarer. Data scientists? Good luck trying to find one.

Shimel: You are not kidding.

Crosby: Hard to find, right? And so there is this workflow which both Amazon and – well, Amazon, Microsoft, and Google posit, which is this: collect all the data; somebody builds a model, trains the model, and then pushes this model towards the edge, where it can do inference. You know, that’s just hypothetical nonsense. Okay? It’s not gonna happen. [Chuckles]

Shimel: Go ahead.

Crosby: And, by the way, so, first of all, you’re gonna collect all the data and, by the way, they’re happy if you do that ’cause then you’re stuck.

Shimel: Right.

Crosby: Right? ‘Cause then you’re stuck on that cloud.

Shimel: Exactly.

Crosby: And then, you know, you gotta find this person to build a model and train it. That’s really hard. And if the data is wrong, then you get over- or under-fitting, and then you gotta push all that stuff to edge. Nobody knows how to do that. It’s just not –

Shimel: No, they don’t. You know, I was talking – I guess it was maybe last week. A friend of mine, actually from this gym we go to – she’s a recruiter. She’s recruiting down in San Jose and they’re trying to get Hadoop folks, just basic Hadoop programmers. And, Simon, look, I know things are crazy in the valley. I think they were paying maybe $240,000.00 or $250,000.00 and they –

Crosby: Unbelievable.

Shimel: They can’t find them, though. They can’t hire them. There’s not enough people with that data scientist, with that type of big data kind of background.

Crosby: There aren’t. And I think, you know, as we move towards a more real-time business environment, organizations are going – let’s posit a future for enterprise IT. Enterprise IT, as you know, today, it needs to change towards something where the gunk is dealt with by somebody else. And then enterprise IT needs to feed real-time insights for different components of the business to the stakeholders, so they can make better decisions.

Shimel: Okay.

Crosby: Yep. And whether that’s supply chain or employees or whatever it happens to be, we need to put enterprise IT into position to deliver real-time insights. And how are they gonna do that? That’s really interesting problem.

Shimel: Absolutely. But there’s something else to what you said too, Simon, that I wanted to hit on and that is – you know, you mentioned – what’d you say? – ARM had 20 billion or licensed 20 billion CPUs?

Crosby: Yeah, per year.

Shimel: Per year. You know, to me, you look at Uber, right? Some people will argue, “Is Uber a software company? Is Uber a drive company? What is Uber?” What Uber really was is they saw a glut of resource, right? People had cars that they weren’t using all the time, that they could monetize. Right? To a certain extent, it’s the same thing here – the amount of computing power on the edge or potential computing power on the edge.

Crosby: Yeah.

Shimel: So massive. Right?

Crosby: Yeah, it’s huge. And so let me give – you’re actually right – so let me give you a really shocking example. So we solve this problem of prediction of traffic and I’ll give you two ways of doing it. And my example is the city of Palo Alto in California.

Shimel: Mm-hmm.

Crosby: And so we get about four terabytes a day from Palo Alto. That’s bigger than Twitter.

Shimel: Wow.

Crosby: Bigger than all of Twitter. Okay?

Shimel: Mm-hmm.

Crosby: So you could take all that data and push it up to AWS Lambda, into a model, and then learn and predict. Okay? Cool. That’ll cost you about $8,000.00 a month. Okay? And learning at the edge, as the data streams off the infrastructure, we bought no new hardware and it costs us pennies.

Shimel: Wow.

Crosby: Okay? So I’m saying thousands of times cheaper than AWS. Okay? So REST, statelessness, and databases are my enemy, number one, and then you’re absolutely right – there is a ton of unused CPU towards the edge, out in this distributed real world.

Shimel: Nature abhors a vacuum.

Crosby: And if I have 10 billion spare CPUs, I mean, I can do an inferencing cycle on Raspberry Pi in the time that it takes a packet to get from the city to AWS.

Shimel: To AWS and then coming back. Mm-hmm.

Crosby: We’re done, right?

Shimel: Yeah. Yeah. Hey, Simon, as I mentioned, the time goes really quick. I wanna focus, ’cause your marketing people appreciate it, Swim.ai. How can people engage? What do you recommend how do they engage?

Crosby: Okay. So what is Swim? Swim is a platform for application developers that want to develop massively distributed, stateful, real-time applications. Okay? It’s a tiny, two-megabyte extension to JVM, okay, which deploys and replaces a huge stack of cloud-based stuff, including the analytics and learning software, the pipelines, Pub/Sub, all the databases you might want. Okay? So we replace millions and millions of lines of code with something very simple.

And it’s an extension of JVM because, that way, we get architecture independence. We found ourselves running ARM and X86 and everything else, all at the same time. And all you have to do is define what’s in your data and then SWIM builds a model for you, trains the model, and does the inference and prediction. Okay? So, simple, right? So the goal here is to make it simple for somebody who is a competent Java programmer, can do a bit of the business of doing really complex analytical stuff on streaming data, towards the edge.

Shimel: Excellent. And, obviously, the website is swim.ai, yeah?

Crosby: Yeah, developer.swim.ai is where you’d go and download it and run apps and everything else. You can download the platform, as well as the example app, so, if you wanna do something like New Relic, download Swim, stick it in each one of your VMs, and you’re up and running in a flash.

Shimel: Excellent. So, Simon, I think I already know the answer to this, but I’m gonna ask it anyway. You have – I mean, your reputation precedes you, your accomplishments. What got you really excited about Swim.ai?

Crosby: You know, if you can deliver improvements in performance and timeliness, which are in the orders of thousands – not 10X, 1,000X, okay? – and really change the world in dramatic way, that’s really exciting. So let me just – let me give you a somewhat critical view of the cloud, right? The cloud vendors make huge margins keeping memory warm for lots and lots of copies of Windows or Linux. Okay?

Shimel: Uh-huh. Okay.

Crosby: And most of that is idle.

Shimel: I got it.

Crosby: Most of those things are sitting there, doing nothing –

Shimel: Just waiting.

Crosby: – while REST happens. And we’ve moved compute from binary into these ASCII-based REST interfaces with lots and lots of pausing. Okay, cool. And now you’re paying for it.

Shimel: Yeah.

Crosby: What I’m saying is that you can do that same computation really enormously cheaply, towards the edge, on stuff you already own. And that’s very interesting.

Shimel: It really – and I could say, “Well, it’s sort of as expected.” Well, Simon, people can go to the website to find out more. You’re talking at any conferences or the company is _____ –

Crosby: Yeah, so we’re launching Swim app at the developer week in Oakland, on Thursday.

Shimel: This Thursday? Which would be February 21st.

Crosby: Yeah.

Shimel: Well, by the time this is up, that might have passed, but they can probably check it out there and see in the website. Well, Simon, if it’s anything like the other stuff you work on, this is gonna be great.

Crosby: Thank you, sir. It’s a privilege to spend time with you.

Shimel: We’ll be watching you closely. We wish you lots of luck. And, you know, living life on the computing edge –

Crosby: It’s fun.

Shimel: It is fun. Hey, man, it’s great catching up with you and best of luck, Simon.

Crosby: Thank you, Alan. It’s great to speak to you again.

Shimel: All righty. Simon Crosby, CTO of Swim.ai. Check him out, computing on the edge. This is Alan Shimel for devopsy.kinsta.cloud. Have a great day, everyone.

— Alan Shimel

April 1, 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