devopsy.kinsta.cloud

Category: DevOps Chats

  • DevOps Chat: Future of the ‘Accelerate: State of DevOps’ Report with Nicole Forsgren

    DevOps Chat: Future of the ‘Accelerate: State of DevOps’ Report with Nicole Forsgren

    “Accelerate – The State of DevOps Report” by Dr. Nicole Forsgren and the folks at DORA (now part of Google) is far and away the most widely cited research in the DevOps field. Dr. Nicole and her team have brought scientific rigor to the survey over these past six years and the results show it.

    Here is your chance to shape the future of the DevOps market by taking 25 minutes of your time and take this year’s state of DevOps survey. These reports are only as good as the info they gather.

    So. have a listen to our conversation and then please go take the survey!

    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, and you’re listening to another DevOps Chat. I’m really happy to be joined by one of my good friends in the DevOps industry today, Dr. Nicole Forsgren, founder of DORA, DevOps Research and Assessment and also now with Google, right, who acquired DORA. Dr. Nicole.

    Nicole Forsgren: Yes. Thank you so much. I’m so excited to be here.

    Shimel: I’m excited to have you here. So, you know, I know what – your title at DORA was very easy, CEO and cofounder, but share with us your title at Google now with the audience.

    Forsgren: Yes. So now – it’s actually pretty similar to what I was doing at DORA. So now I am doing research and strategy with Google Cloud and I’m still leading all of the dope, fun, amazing DORA work, so DORA is still continuing. We’re still doing all of this exciting external industry amazing work that’s DORA. And actually, that’s what we get to talk about today, right?

    Shimel: Absolutely. So, you know, March 14th was five years we’re publishing devopsy.kinsta.cloud, and over that time, you know, a lot of water under the bridge, but there are certain foundations that the DevOps community – and I don’t mean just practitioners, I mean the vendors, I mean the evangelists, the leaders, the followers, the laggards, the early adopters – there are just certain foundations that we’ve built this on and one of them is the State of DevOps Survey that you’ve been doing now I’m gonna guess it’s six or seven years, right?

    Forsgren: This is – yeah, this is year six.

    Shimel: Yes, six years, and –

    Forsgren: It’s a kid. [Laughs]

    Shimel: It still is, but you know what?

    Forsgren: It’s a small child now. [Laughs]

    Shimel: Let me see if I remember because I don’t have notes in front of me, Nicole, but over the six years you’ve collected was it 25,000 or 27,000 responses, something like that?

    Forsgren: Yeah, yeah, we’re right in there.

    Shimel: Yep. And what’s great is over these six years you’ve disseminated so much of the information, and that information and those results of the survey really form the basis for so much of the Dev – of what we think we know anyway about DevOps and Agile and Lean and all of these things that, you know, come together. So much of what the whole thing is premised on comes from the results of this survey, so congratulations on that and thank you.

    Forsgren: Thank you. Oh, yes of course. I love it because it helps us understand what we do that’s important and impactful, and it backs up so much that, frankly, some of us know and have done for a decade now, right? So I started so much of this back – you know, I’ve chatted about this, right? – back in my dissertation work about a decade ago, and even so much of what I did as an engineer and as a sysadmin, even before that, but as we know as good little scientists and good little experimenters, right, we need more than just intuition. We need data.

    We need to know what’s working and what’s working consistently in part so that we can keep doing it and sometimes so that we can convince people, whether it’s convincing ourselves, whether it’s convincing leaders, whether it’s convincing our teams so that we can say this is what we’re gonna do and this is what we’re gonna keep doing. And so, yeah, sometimes people will read the book Accelerate, you know, that I wrote with Jez and Gene, or they’ll read the State of DevOps reports and they’ll say, “Oh, well yeah, I knew that.” Well that’s great because so often that’s where we get our hypotheses from, right? We’ll reach out to the community, we’ll go to conferences, we’ll speak with engineers, we’ll check Twitter, we’ll read our emails, we’ll speak with so many people in the community and we’ll say, “What are you hearing, what are you seeing, what do you think is working, what’s not working?”

    And we’ll look at the things that are like consistently working or maybe there’s mixed signal and we’ll say, “Okay, these are the hypothesis we want to test,” because that’s – like that’s how you do science, right? You form a hypothesis and then you go to test it.

    Shimel: So you just said the magic word – science – because, you know, it’s interesting, there’s something – depending who you believe, there’s 400 to 700, 800 vendors in the DevOps space, and I’m gonna bet half of them, maybe more than half, do some sort of – excuse language – but some sort of half-ass survey, right? Where they’ll put out a survey on SurveyMonkey and they ask questions, they get answers, and I am constantly bombarded by PR agencies who say, “You know, our survey found 42 percent of people did this, 36 percent of people did that, blah, blah, blah, blah.” There’s no real science behind these surveys, right? The questions are done in – it’s like political surveys, right?

    Forsgren: Right. Yeah.

    Shimel: They tell what the answers are – they – what answers they want, and they –

    Forsgren: Because they want to support their own product.

    Shimel: Of course.

    Forsgren: They want to support an agenda, and I understand why. I mean I get it.

    Shimel: You know, they’re _____ their own socks, as we say, [laughs] but–

    Forsgren: Yeah.

    Shimel: – I think one of the things, you know, why you’re sitting here at Google right now, right, and why you’ve have the success you’ve had is that there’s some academic – what’s the word I’m looking for?

    Forsgren: Rigor.

    Shimel: Rigor. That’s the word I’m looking for. There’s some academic rigor to this survey and I think that is a big reason for its success. I mean, Nicole, I’m going all over the world and people will throw out, you know, stuff to me, and I say, “Where did you get that number?” They say, “Oh, the State of DevOps Report 2018, 2017,” you know, and I’m like, “Oh, okay. Pretty cool.” You know, so it’s a amazing thing. But of course –

    Forsgren: Well, and I think it’s because we don’t have anything to sell.

    Shimel: Exactly.

    Forsgren: Or let me say the thing I have to sell is better outcomes, and I am happy to be convinced at any time with data and with results. If my–

    Shimel: And that’s science.

    Forsgren: That’s science. If I get my mind changed – and there have been a couple times when my mind is changed and I am reconvinced of another position because we want better outcomes. This work is born of my experience in the early 2000’s. I entered technology in ’98, ’99, 2000 in – and I’ve said this before – in the dot.com bust, and it’s interesting because people are like, “But the dot.com bust didn’t happen, right, the world didn’t end, you know, the Y2K bug didn’t end the world,” but what did happen is some systems failed, some companies failed, so what happened?

    Companies fail, people lost their jobs, families were torn apart. We’re seeing some of that trickle down again, so if we can improve outcomes, if we can make companies more successful, deliver value better, if we can make work better, if we can decrease burnout, if we can make work/life balance better, if we can make pushing code easier so we’re not doing seven-day forced marches – ’cause I did that for two years.

    Shimel: Right.

    Forsgren: If we can make work better we all win.

    Shimel: Absolutely.

    Forsgren: Everything gets better.

    Shimel: Well, and not only those folks who were slinging code and stuff, the world wins because, you know, I was just – right before I got on this podcast with you I was doing a video with another guest and, you know, we were talking about Charlemagne scribes. I don’t know if you know anything about this, right?

    Forsgren: Yes. Well, let’s catch everyone up.

    Shimel: He was illiterate, Charlemagne, so he counted on his scribes to tell him – well, the Bible was kind of the only book they had, but he counted on his scribes to get him the intelligence, to make him smart, to show him the way, to let other people know what he was doing and all of these things. Today, technologists, developers, and DevOps folks and stuff like this, those of us in the tech world, we’re sort of Charlemagne’s scribes, right? It’s almost within our hands to make the world a better place. And I don’t want to overemphasis it,  but it’s true.

    Forsgren: But if we can make things more accessible for more people and more places across broader populations –

    Shimel: Yeah. No, even just something –

    [Crosstalk]

    Forsgren: – it really changes the conversation.

    Shimel: – as simple as the black hole picture last week, right? I’m sure you looked at it.

    Forsgren: Of course.

    Shimel: I mean what a great story this is, right? I’m not even gonna get into the idiots who were giving this young woman a hard time, that she really wasn’t the driving force, but what a great – I mean to be able to sit at our desk and peer into what a black hole looks like, the inside of – you know, that’s what it all comes down to, but we can’t do those algorithms, we can’t do that data without the science, right? Science feeds science. But anyway, Nicole, a lot of people have asked me, you know, with DORA now acquired by Google, are they doing the survey? Is it gonna be the same? What is the story? Tell our audience.

    Forsgren: Yes. Yes. Okay, so the survey’s still happening and it’s happening now.

    Shimel: Okay.

    Forsgren: So for anyone who hasn’t taken the survey it’s open right now. It’s about 25 minutes, and right, everyone’s like, “Girl, 25 minutes,” but it’s because it’s that academically rigorous research. So what are we studying?

    Shimel: But haven’t they always been about 20, 25 minutes?

    Forsgren: It’s always been about 20, 25.

    Shimel: Yeah.

    Forsgren: And I’ll still love everyone who does it. I’ll come, like, hang out with you and, like, selfie with you and give you a hug or give you like an elbow bump, whatever you want to do.

    Shimel: Well, we might be talking thousands and tens of thousands of people, Nicole. You know, _____.

    Forsgren: That’s fine, we’ll hang, we’ll hang.

    Shimel: Let’s talk about the survey, though. First of all, is there like an easy URL we can talk to people? I’m gonna put the written URL in our show notes, but do you have an easy-to-remember URL that people can _____?

    Forsgren: Yes, yes. So it’s bit.ly/2019-ASODR, A-S-O-D-R, ’cause – for accelerate State of DevOps Report.

    Shimel: Accelerate State of DevOps Report, ASODR.

    Forsgren: That’s – so bit.ly/2019-ASODR.

    Shimel: So bit –

    Forsgren: nd anyone who’s in tech – well, anyone can go take it, but I would love to hear from our devs, our test, or ops.

    Shimel: Security people.

    Forsgren: Yeah, yeah.

    Shimel: Don’t forget our security DevSecOps people.

    Forsgren: Oh sure, Infosec, absolutely.

    Shimel: So, Nicole –

    Forsgren: And we’re digging into cool stuff this year.

    Shimel: That’s what I wanted to ask you. What’s different this year?

    Forsgren: We say it every year. I know. I get excited every year. But we’re really digging into cool stuff. So I reached out to some extra experts this year, so automated testing and testing in a slightly different way, right, because testing’s changing. The way we think about testing is changing. We’re also looking at how to build effective deployment pipelines a little bit differently. Disaster recovery practices, right?

    Shimel: Yeah.

    Forsgren: As our systems get more distributed and more complex, disaster recovery is super important. Things like our technical environment; what does that look like, right? So, so many things. I can’t say all of it. Productivity.

    Shimel: So let me – give me a timeframe. Timeframes, Nicole.

    Forsgren: Okay. So the survey’s open until May 3rd.

    Shimel: We got –

    Forsgren: And I know everyone’s like, “I got plenty of time.” You got – I mean kind of.

    Shimel: No, go do it now.

    Forsgren: A couple weeks. Do it now. And then the survey comes out in August, like mid-August.

    Shimel: Oh.

    Forsgren: And I know everyone’s like, “That takes a minute,” but it takes a minute to do science. It’s a lot of stats and then writing and then I gotta make it pretty because –

    Shimel: Was that always the time? I seem to remember it coming out around DES in US, around like October.

    Forsgren: So it always takes about six months. It used to come out June-ish and then –

    Shimel: Oh, maybe it was DES London.

    Forsgren: Yeah, it was DES London, and then last year we shifted a little bit to fall because I just think it took me a minute to pull together research, design it –

    Shimel: Oh, it takes time.

    Forsgren: _____ in December, because what I – here’s the thing: I love to hear all of the feedback from the whole fall conference schedule. It gives me a better chance to really get great signal from what everyone’s hearing and what everyone’s saying.

    Shimel: Yep.

    Forsgren: And then I start pulling together all of my research design in January and February and then we launch in March, so it takes about six months to pull together a really, really good research study.

    Shimel: Look, all this is good by me. I was expecting October for DES, so I just – you know, I just picked up two months.

    Forsgren: Yeah, yeah.

    Shimel: So it’s good by me. Alright. And now Google, of course, is obviously sponsoring it again this year, Google Cloud, with your –

    Forsgren: They are – yep. So we’re partnering with them this year like we did last year.

    Shimel: Yep.

    Forsgren: And then we have lots – we have got a handful of other sponsors just like we do all the time, right?

    Shimel: That’s what’s changed in this regard.

    Forsgren: Because this is such a great industry report, right?

    Shimel: Yeah.

    Forsgren: And so we’ve got a handful of wonderful – and it’s still under wraps – but we have amazing, wonderful industry partners and sponsors.

    Shimel: Oh, good.

    Forsgren: Like we always have, right? So it’s still the DORA Report, it’s still – you know, we still have the DORA team behind it, and I’m super excited to share the results with everybody in August.

    Shimel: So we’re excited to read about it. So let me – I don’t know if you can say this or not, but will we see a second Accelerate book?

    Forsgren: [Gasps] Probably. Well, because the first book was based on four years of research.

    Shimel: Right.

    Forsgren: And then we had a 2018 study come out that had some incredible findings like cloud, right? Everyone’s like, “Okay, cloud, but does cloud matter?” And some people are like, “Okay –” science, right? Here’s a great example of science. Some people are like, “Of  course cloud matters. Cloud makes a huge difference.” And then there’s some groups that are like, “We made these huge investments in cloud, but I’m not seeing the benefits of cloud.” So here’s what we found: Cloud matters but only if you do it right.

    Shimel: Yeah.

    Forsgren: Some people are like, “What do you mean do it right?” If you follow the five essential characteristics of cloud computing as defined by NIST, the National Institute of Standards and Technology, we see that you’re 23 times more likely to be an elite performer. See? Stuff like that is super important because that’s really what helps you tease out the differences.

    Shimel: I wish I would’ve had this in my – you know, Nicole, I was in Iceland last week at a conference – a small one, 50 – more of a roundtable, 50 people, all high execs at large enterprises, and we – and there was someone giving a presentation there about, you know, advantages, disadvantages, cloud, hybrid cloud, et cetera, and man, I could’ve used some of these metrics there because –

    Forsgren: But see that’s what helps you tease out yes it makes a difference but only if you’re actually doing it right. You can’t skip steps. You have to execute. And then you can go back to an exec team who says things like, “We made investments, it doesn’t work.” Okay, but did you execute all the way? Did you execute fully? Are you so early in your transition that you’re just not seeing the benefits yet but they will come; don’t give up.

    Shimel: Well, this is – I have to say I’m arguing with people with DevOps who tell me their DevOps failed or whatever.

    Forsgren: Oh, absolutely.

    Shimel: DevOps only fails when you stop doing DevOps and –

    Forsgren: We see the same thing with CI/CD, right? We’ll see teams do a continuous integration initiative and then they’ll redefine it so narrowly to make sure that they hit their target, but then what happens is if you go reevaluate – I think that’s the benefit of the research, is because we have to do it rigorously we end up identifying _____ exactly what it means to do CI. You have to hit four things, which gives you an evaluative criteria. So then you can go back and you can say, “We’re doing CI but I’m not seeing benefits.” Okay, go back to the book. We outline it for you. Are you doing all these four things? And you could say, “Oh, we’ll we’re only doing two.” Okay, that’s why you’re not seeing the benefit.

    Shimel: [Inaudible comment]

    Forsgren: You have to have all four.

    Shimel: But Nicole, this is an excellent reason why people need to buy the book. It makes a big difference.

    Forsgren: Yes, and this is also an excellent reason, by the way, please take the survey because –

    Shimel: Yes.

    Forsgren: – what helps me understand which things are predictive of performance, which things are not, and then you can turn back around. The report is free. It’s free to download. Anyone can go back through and you can see, okay, absolutely these are the things we should continue doing, these are the things that are not helpful and not beneficial. So, by the way, I super – like I love and appreciate anyone who helps contribute to all of this research, but we do pay it forward. We absolutely contribute to the community.

    Shimel: Absolutely do, and I think our entire industry should pay it forward by participating. Nicole, as I mentioned to you before we started, this is only a 15, 20-minute interview. We’re close to the half hour, but –

    Forsgren: [Laughs] Sorry. Thanks, everyone. I love this community.

    Shimel: Absolutely. But let us end with this then. Please go take this survey. It’ll take 20, 25 minutes, and the URL to go take it is bit.ly, which is, of course, B-I-T dot L-Y, slash 2019 slash A for accelerate –

    Forsgren: Dash, ASODR. Yep.

    Shimel: ASODR.

    Forsgren: Sorry, bit.ly/2019-ASODR.

    Shimel: ASODR, spell that for us.

    Forsgren: A-S-O-D-R.

    Shimel: ‘Cause, you know, I had – I’m from New York. We have a tough time with R’s at the end of words.

    Forsgren: I know.

    Shimel: Like brother, sister, and all that. I can’t help it.

    Anyway, Dr. Nicole Forsgren, thanks so much for being our guest. Guys, gals, listening; go take the survey. Nicole, hopefully – I guess I’ll see you in London next perhaps and –

    Forsgren: Yes, yes, for sure.

    Shimel: Unless maybe at KubeCon in Barcelona is very nice, but I don’t know if you’ll be there. If not, DES London.

    Forsgren: Absolutely.

    Shimel: Alright. Dr. Nicole Forsgren, CEO and founder of DORA, big-time person at Google Cloud as well, and the – kind of the life and breath of the State of DevOps Survey. Thanks for being our guest on this DevOps Chat.

    Forsgren: Thanks so much.

    Shimel: Alright. This is Alan Shimel and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Performance Testing with SmartBear’s Keshav Vasudevan

    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

  • DevOps Chat: Aqua Security Talks Funding, Security in a Cloud-Native World

    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

  • DevOps Chat: F5’s NGINX Acquisition, with F5’s Lori MacVittie

    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

  • DevOps Chat: Chef Goes All-In on Open Source

    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 20th – 23rd 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 19th and 20th, 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

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

    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

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

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

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

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

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

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

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

    Transcript

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

    Kohsuke Kawaguchi: Thanks for having us again.

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

    Tracy Miranda: Yeah, [inaudible].

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

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

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

    Shimel: I think it might have been 25.

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

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

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

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

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

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

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

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

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

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

    Miranda: [laughter]

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

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

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

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

    Shimel: Yeah, please.

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

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

    Miranda: Google and Netflix for –

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: In May.

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

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

    Miranda: Yeah, that would be awesome.

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

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

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

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

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

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

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

    — Alan Shimel

  • DevOps Chat: Doing Agile, with AgileCXO’s Jeff Dalton

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

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

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

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

    Transcript

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

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

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

    Dalton: Yeah. Right?

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

    Dalton: Go to the beach?

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

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

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

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

    Dalton: It sure is.

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

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

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

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

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

    Shimel: Yeah. For sure.

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

    Shimel: Good for you—

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

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

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

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

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

    Shimel: No.

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

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

    Dalton: Right.

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

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

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

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

    Dalton: Right.

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

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

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

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

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

    Dalton: Sure, yeah.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Dalton: Right. Yeah.

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

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

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

    — Alan Shimel

  • DevOps Chat: Customer Experience and DevOps with Cyara’s Alok Kulkarni

    DevOps Chat: Customer Experience and DevOps with Cyara’s Alok Kulkarni

    In this DevOps Chat we speak with Cyara CEO and co-founder, Alok Kulkarni, about how DevOps is helping in the customer experience arena. Cyara has carved out a leadership role in bringing DevOps to CX. Alok is a delight to speak with and very wired into this space.

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


    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Alok Kulkarni, CEO and Co-founder of Cyara. Alok, welcome to DevOps Chat.

    Alok Kulkarni: Hey, Alan. Great to be here.

    Shimel: It’s our pleasure to have you here. So, Alok, let’s—before we jump right into what I wanted to talk about today, I think the first thing we should do is a little level set. Maybe we have some folks who are familiar with Cyara, maybe we have some folks who are not. Why don’t you give us kind of a quick background on Cyara?

    Kulkarni: Sure, Alan. So, Cyara is a customer experience assurance platform, which allows customers to accelerate their CX development right from the design through to testing and all the way through to customer experience monitoring for customers’ journeys end to end.

    And so, what’s different about us is, we support the entire software development life cycle from the design through the functional integration testing right through to user acceptance testing, including load testing and production monitoring. And, in the CX world, we’re able to do this from an end customer perspective across all the different channels that the customer might be interacting with the organization. So, that’s just a brief summary of what we do.

    Shimel: Sure. And you are the Co-founder and CEO.

    Kulkarni: Mm-hmm.

    Shimel: And just, while we’re here—

    Kulkarni: Yes, and—

    Shimel: —give us a little bit of your own personal journey. How did you come to be the co-founder and CEO at Cyara?

    Kulkarni: Sorry, go ahead.

    Shimel: Oh, I’m sorry. I was going to say, if you can give us a little bit of your own personal journey, how did you come to be the CEO and Co-founder of Cyara?

    Kulkarni: Oh, great question, Alan. Sorry, I lost you there for a bit. I was working at another software company, which is currently the leader in customer experience management technology, and one of the things I found in those days—this was in the late 2000s—was, every time we put the technology in production, the customers, the end customers used to deal with this new technology and the enterprises would be sitting there with white knuckles hoping and praying that it would all work—because there was no platform in those days which would enable them to test and monitor the technology that they were putting in for the customers from the outside in. So, essentially, it was like playing Russian roulette.

    So, I felt, being an architect at this company and managing the solutions engineering group at this technology company called Genesys that, there had to be a better way. And one of the—the idea came to me when we were rolling out a large implementation for an Australian government organization when it failed. I thought that there must be a better way of doing this.

    So, hence, I felt—imagine if there was a cloud-based platform that was technology agnostic which enabled enterprises to just use and simulate customers from the outside in to be able to test and monitor, not only the infrastructure, but the applications from an end to end customer journey perspective. It would really take the risk out of deploying new and innovative solutions in the market. And so, that’s how it all happened. So, I got together with my buddies and we built Cyara.

    Shimel: Excellent. So, you know, in so many ways, there’s so much DevOps there, if you will, Alok. And first of all, the idea of—and we see this in security, we’ve seen it with other forms of QA—the idea of waiting ‘til after something is deployed to see if it works or not, you know, that white knuckle moment? Why?

    Kulkarni: Mm-hmm.

    Shimel: I mean, why, in this day and age, do companies still want to do stuff like that, right? And this is, especially when we talk about sort of the modern software factory and CI/CD pipelines and so forth, right? We shouldn’t let software out there that hasn’t been fully vetted and tested. Why would we let software and things in the wild, where we haven’t already tested what our customer response, and our customer experiences are going to be and whether they will work?

    It just seems like such a no-brainer. Why do you think it took so long for people to come to this realization?

    Kulkarni: So, I think that’s a great question, Alan. And, you know, when we were sitting there noodling on whether we should start this, I remember going to my co-founder, Bonny, and asking him, “Hey”—because he wasn’t from the industry, and when we came up with this idea, he goes, “Surely, there’s somebody doing this.” Because it’s exactly what you said—it’s a no-brainer. And I said, “No, there’s actually no one doing this.”

    And I think the reason for that is, one is, I don’t think people in the—if you’re not in the industry, you don’t even know that this is a problem, that’s one. Second thing is, even if you were in the industry, it is so complex. I mean, there are so many different moving parts, so many technologies. Then you have enterprise processes and systems and systems integrators and so forth.

    So, by the time you’ve put that whole, all those components together, it becomes very difficult to build something simple that would solve these problems. So, when we did it, it just took off. And now, like you say, I think customers are realizing that there is a technology or a solution out there that can help them. So, we’ve had a tremendous, I guess, following of customers who actually just continue to expand what they do with Cyara and we’re signing new customers on as we go along.

    So, just this last quarter, we signed about 25 Fortune 500 companies to our platform. So, I think it’s catching on, and now, what we’re seeing is the next wave, like you mentioned, this whole DevOps wave that’s really taking firm hold in the way that more and more organizations are putting out a software or capability. And I think in the CX world, that’s changing as well. So, I think, we’re also creating awareness that you can bring DevOps to CX and although the tool set might be a little different, you can actually do it. So, we’ve had a tremendous amount of traction in the market with that.

    Alan Shimel: Absolutely. You know, Alok, it talks to something else that we’ve seen in DevOps. When we first started devopsy.kinsta.cloud on March 11th of 2014, I think it was, so it’s almost five years now—the whole, “What is DevOps?” argument was raging. And there was a large percentage of the community that had a very orthodox view of DevOps, that if it wasn’t purely about software development and deployment in terms of operations and APM, it wasn’t DevOps, right? That’s what—there was a very narrow definition of DevOps.

    We’ve seen that expand, right, to what I call DevXOps now.

    Kulkarni: Mm-hmm.

    Shimel: We’ve seen DevSecOps, we’ve seen DevBusOps, we’ve seen DevSalesOps. It’s really taking that DevOps mindset that DevOps can do and applying it to everything.

    So, really, we’re almost seeing here DevCXOps, right, if you will.

    Kulkarni: Yeah, totally. Yeah, I think we are in that era now of DevCXOps, just like you mentioned. Because, just like software organizations were putting out new capabilities in a rapid manner, I think customers were expecting customer facing technologies, and the way they’ve been—the way that they’re interacting with organizations to change rapidly as well. Because everyone’s time poor, they need the answers as soon as something goes wrong or if they want to buy something, they’re impatient, because we all have things to do and we’re on 24/7.

    So, it’s imperative for companies providing customer experience to keep up with that. And I think DevOps provides a great framework to do that, and it’s aligned so, as you say, if you’re already in DevOps and the digital world, you can bring it to the CX world. And I think it’s really catching on.

    Shimel: I don’t disagree. I think another thing, Alok, and you hit on it there, is customer expectations. You know, one of the sort of forgotten heroes or the forgotten catalyst behind all of the DevOps kind of movements is what really—people don’t go fast just to go fast. Well, maybe some do, right? There are speed freaks, right? [Laughter]

    But, you know, people who adopt agile DevOps and these sorts of frameworks and methodologies do so to be more responsive to customers. And that’s really—and it’s nitty-gritty. That’s what it’s about. Because that’s why companies do things, to serve their customers better. And that’s really the guiding principle behind CX as well, right? How do I respond to customers better, especially in a world where customers demand more? They want 24/7 support and response, and they want it right away, and they want it now and they want it to work, right? There’s a low tolerance if your cellphone coverage is not good, or your internet—as we spoke about—your Internet at 30,000 feet on a plane is not working, and people get really upset about that now. And in so many other ways, customer demands are driving this. Correct?

    Kulkarni: Yeah, totally. And you know, what’s sad is, we’re fickle. You know, we’ve been conditioned to now have choice. So, if we don’t like the service a particular company is offering, you know, we switch, and switching is so easy, because it’s very easy to find another provider who provides a similar service and offering and then if they have a better customer experience, you think when you actually have that moment of need where you actually need help and they’re providing it to you promptly and they’re resolving your issues quickly and they’re doing it how you want to be treated, maybe it’s a late night chat or a phone call because it’s super urgent or it’s complex. Or maybe it’s like, “I don’t want to talk to anyone today, but I need the information for my support, because one of these technologies that I’ve got isn’t working, so I need a knowledge base that I can refer to.”

    Any of these customer-facing technologies play a very important part in customer loyalty and thereby, shareholder value for the company that they’re dealing with.

    Shimel: Agreed, agreed. So, Alok, if you don’t mind, I want to talk a little Cyara—I’m sure you don’t mind. [Laughter]

    Kulkarni: [Laughter]

    Shimel: So, do you offer this as more of a Platform as a Service or as a SaaS based offering?

    Kulkarni: Yeah, it’s a SaaS-based offering, so we have a cloud infrastructure environment which spans, which goes across the globe. Just last year, we placed 4.4 billion call seconds’ worth of synthetic interactions to assure customer experience around the world, and some of the largest brands of the world use it.

    So, some customers, they use our platform to provide the whole design experience—like, the design, the customer experience in Cyara is able to, as a result, get a full automation and regression test suite that they can run as part of their DevOps factory, and then we have a real time customer experience monitoring platform.

    So, for example, if you put something out in production, our platform actually is able to generate synthetic customer interactions from the outside in. So, we can actually emulate, Alan, contacting an organization on your behalf and actually see what experience you’re going to get, whether your interactions or your calls connected on time, whether the web chat gave you the right responses, whether the screen froze or not, and you can do this all in real time.

    So, customers have a direct feedback loop that they can implement. So, as soon as something goes into production and it doesn’t work, before a real customer is able to have a poor experience, we’re able to detect it early on and the customers can then roll back the technology that they had implemented and then roll the previous last known good version out so that they maintain the sanctity of the customer experience.

    So, it just—to me, that just goes hand in hand with the whole DevOps paradigm.

    Shimel: I agree. It certainly does. So, Alok, if I ask you to kind of peer into your crystal ball of the future, where do you see this going now?

    Kulkarni: So, as you mentioned, Alan, there’s a lot of companies out there who are not even aware that they can apply the whole DevOps—they can bring CX to DevOps and, as you call it, DevCXOps, and make it happen. So, I feel, over the next two years, we’re going to see a tremendous wave of customers adopting this framework, because they’ve already done it on the digital side and the CX side tends to be—I think they’re in an adjacent area and I think they are moving to this new model.

    So, we’re going to see a lot of customers offering it, and I think we’re going to see a lot of new, innovative technologies coming out with integrated solutions for that. So, I think for Cyara, we want to support our customers as they go on this journey. So, we’re integrating with a number of platforms out there that enable the whole CX DevOps pipeline scenario. For example, we’ve just integrated with Splunk, we’ve integrated with ServiceNow. So, in Cyara, you can actually get real time incident notification of any technology that you’re implementing and automatically create service requests so that you’re able to keep ahead of the whole customer experience pipeline.

    And the other thing that we’re doing is also investing heavily on the design aspect of it. So, we’re working with companies like Amazon and so forth to offer a platform that is able to take customers that are moving to the cloud or moving to cloud contact centers, which is becoming, which is a new wave that’s still catching on and enable them to essentially drive this whole assurance through to all their customers.

    Shimel: Excellent, excellent, excellent. Well, Alok, as we—I think I told you before we started, the time goes really quick. We only have a few minutes left. I wanted, also, I’d like to finish up with kind of wrapping this whole thing back into the DevOps, back into what Cyara is seeing from customers.

    Companies I’ve been involved in, and I’ve founded a few, you know, we had sort of a customer support, a customer help team. It was separate from developers, it was separate from Ops. It was part of the engineering team, but it was almost a red-headed stepchild within that engineering/IT team. Is that still the case? Is that a problem? Is that something Cyara runs into when you’re talking to folks? What’s the story?

    Kulkarni: So, I think you, again, Alan, are right up there with it. So, I think one of the decisions organizations that we deal with are grappling with is, do they make engineers who understand software and make them CX developers, or do they make CX developers who have real code domain expertise and bring them onto the DevOps world?

    And I think that’s a question a lot of companies are asking themselves—like, do we need to really understand this space from top to bottom, or do we get developers? Is it easier for developers to learn this versus the other way around?

    And I think that’s currently in the experimentation stage. So, a lot of companies who have tried the old model feel that it’s just very hard to change the mindset of the old engineering folks to—you know, who’ve been traditionally used to waterfall and doing large scale implementations and using systems integrated to put those out to really just come onto this whole new, you know, go fast, break things mentality versus getting those guys to understand CX.

    So, I think there are two horses running right now, and I think we’ll see the results of that in the next year or two. But what I am seeing is a lot of companies trying to get their developers onto the CX world, because they’re finding that that seems like a much easier path.

    Shimel: I don’t disagree with you. Crazy. Interesting times.

    Kulkarni: Yeah.

    Shimel: Anyway, Alok, I know we’re doing some other, you’ve published some more—well, not you, but Cyara has published some nice articles on devopsy.kinsta.cloud lately, we’ve done some other activities.

    Where else can people find out more information, though, about Cyara?

    Kulkarni: Well, they can obviously come to our website, so Cyara.com, that’s C-Y-A-R-A dot com. And I think we have, we’ve built a huge library of resources thanks to our fantastic team that we have at Cyara, and they can also—I think over there, there’s a whole library of collateral that they can view. We’ve got a YouTube channel that they can subscribe to.

    And we also have Cyara Academy. So, as part of that, they can go in and if they want to actually get trained on Cyara, we offer that on demand as well. And you don’t—I think there are some courses where you don’t have to pay. So, I think you can, if you’re new to this space, I think it’s a great place to get scaled up, because I think this is a very exciting space. Because, as you’ve said, Alan, every company, to be successful, needs to really deliver a superior customer experience to their end customers and I think it’s just the core of any fundamental for any company to get this right.

    So, come on over to Cyara.com and get yourself educated.

    Shimel: Cool. Well, Alok Kulkarni, CEO and Co-founder of Cyara, thanks for being our guest on this interview, on this episode of DevOps Chat, and we hope to have you back on again soon.

    Kulkarni: Thanks, Alan. Would love to come back.

    Shimel: Alrighty. Hey, this is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard, Container Journal. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: AppSec and DevSecOps with Contrast Security’s Jeff Williams

    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