Author: Alan Shimel

  • EP 3: Open Source and DevOps

    EP 3: Open Source and DevOps

    In the third episode of our DevOps Unbound streaming broadcast on TechStrong TV and devopsy.kinsta.cloud’s sister site Digital Anarchist, Alan Shimel is joined by Kevin Dunne of Tricentis, Tracy Miranda of CDF and Alon Girmonsky of UP9 to answer the question: Can we have DevOps without open source?

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Alan Shimel: Hi everyone. Welcome to another episode of DevOps Unbound. DevOps Unbound is sponsored by Tricentis, so many thanks to them. But it’s our show here at MediaOps and we try to explore, you know, just some of the areas around DevOps and not just dev and ops but DevOps as a framework for the way things are being done, the way application and software is being made and deployed today, the way it’s being hosted, the way it’s being operated and maintained and observed, and so many other aspects of how we’re doing technology. 

    It airs every other week and this episode is episode number three of DevOps Unbound. Hope you’ve enjoyed the first two.

    With that let me introduce to our panel today. First of all, well, it may not be right or left on your screen, because so it makes no sense to tell you how it is on my screen, but let me first start off with my friend, Tracy Miranda. Tracy is the executive director of the Continuous Delivery Foundation, which is a Linux Foundation and a sister organization to Cloud Native Computing Foundation. Got that all out of the way. Tracy, welcome. 

    Tracy Miranda: Hi everybody and thanks for having me Alan. 

    Shimel: My pleasure to have you on Tracy.

    Joining Tracy and I today, I have Kevin Dunne, who has been on our TechStrong TV in the past. Kevin is with Tricentis and runs their open-source communities, as well as some of the open-source projects that are now under their management, some by acquisition over the years, some they’ve developed themselves. But Kevin, welcome to DevOps Unbound. 

    Kevin Dunne: Thank you, Alan. Happy to be on and glad you’re having us back with you again. 

    Shimel: That’s our pleasure. 

    Then last by not least is my friend, Alon Girmonsky. Alon is the CEO/founder of UP9, that’s U-P-9. He’s going to tell us about that when I ask everyone to introduce themselves here in a moment, but Alon was also the founder/CEO of BlazeMeter, a very well known open source or player in the open-source testing world acquired by CA, which of course became Broadcom. 

    So, today’s episode ladies and gentlemen is around DevOps, cloud native and open source more importantly, most importantly, and how important open source is to this whole DevOps movement and this whole — Someone today, I had someone from Deloitte Cloud on and I was doing an interview called it a “revolution” that we’re seeing, especially since COVID, right? IT has undergone a revolution of cloud transformation, digital transformation, acceleration and so much of it is made possible by open source. So that’s our subject today. 

    Before we hop into it I wanted to give each of you like 30 seconds, just in case our audience wanted more than the cursory kind of introductions I did. Why don’t we start with you Kevin? Give them who you are, your background and we’ll jump through all three of us from there. 

    Dunne: Yeah, that’s great. My name is Kevin Dunne. I’m with Tricentis as Alan mentioned. My main focus is on our open source and sort of community products. I’ve been with Tricentis for seven years. Prior to Tricentis I was at QASymphony, which merged with Tricentis about two years ago. So very passionate about open source, it’s been sort of a new area that Tricentis has been getting into. 

    There was a lot of work around Flood, which was built on top of JMeter and Gatling and now Tricentis has acquired TestProject which is built on top of Selenium and Appium and most recently SpecFlow which is an open source project based on cucumbers. 

    So I’m really excited to see how these tools are helping to kind of shape the Tricentis roadmap and sort of broaden the community in the open source supports, so very exciting projects going on so far. 

    Shimel: Alon, how about you?

    Alon Girmonsky: Hey everyone and Alan thanks for inviting me. I’m a big fan both of Tricentis and obviously the CD Foundation. Alon Girmonsky as you mentioned my current company UP9, which I have the privilege of being cofounder in, deals with microservices and cloud native in respect to testing. Testing is something that is becoming harder and harder to do, especially when you know you talk about service testing and API testing. So UP9 provides a solution for somewhat autonomous, mostly automatic you know service testing. 

    As you mentioned prior to that my previous company, BlazeMeter, was all about load testing and stress based on the open-source tool JMeter. You know I had the pleasure over the past 10 years to be involved in the open-source community and understand or at least try to understand what’s the place of open source and why is it so important specifically for developers. I’m very happy to have the opportunity to discuss this in this forum. 

    Shimel: Last, but not least Tracy how about you?

    Miranda: Tracy, I’m the executive director of the Continuous Delivery Foundation or CDF, which is an open-source foundation with the mission to improve the world’s capacity to deliver software with security and speed. The CDF is home to the open-source project Jenkins, JenkinsX, Tekton and Spinnaker. 

    Before that I was leading open-source community at CloudBees. In general I’m a 15-year veteran of open source, so I love all things open source, open innovation and building communities. 

    Shimel: Excellent. So folks, here’s my opening premise and we’ll let — it will be our jumping off point. 

    I also have a long involvement in the open source world. I first got involved in open-source security related projects 2002, 2001 and we were blessed in security to have some amazing open-source tools at our fingertips. Products like Snort, which was developed by Marty Roesch, who then started Sourcefire, acquired by Cisco, was the de facto standard for intrusion detection. The NMap and Nessus scanners, Renaud Deraison, who’s cofounder over at Tenable Network Security and Ron Gula, who started Tenable with Nessus. NMap has been out there. There were many others, ClamAV and so many commercial companies actually sprang up just by using that open-source software under the covers putting a UI on it and stuff. 

    So I’ve seen open source. I remember talking to CIOs and I remember speaking to you know a DOD agencies about their use of open source and they would tell me that they don’t have any open source, they don’t allow open source and then you would go look at what their developers were working on and it was all open source, you know it was Linux and everything else that they had, just didn’t bother telling them about. So I’ve seen open source become from a gorilla-type of operation in many environments, to the dominant form of software and software development today. 

    When I got into DevOps it became really apparent to me and this is my jumping-off point, we wouldn’t have DevOps without open source. I just don’t think — I think so much of what we can consider not only the tools of DevOps, so specific open-source projects, but the culture of DevOps, the collaboration, the sharing of knowledge of DevOps is based upon that open-source mindset, on the open-source culture that you couldn’t have DevOps without open source. 

    Tracy, you ran the open-source community of CloudBees first and only ED at CDF, part of Linux, what’s your feeling on that? Why don’t you kick us off? 

    Miranda: Yeah so definitely as a big fan of open source I’ve seen how it’s been really instrumental to DevOps. I think you know one of the things that open source does really well, like sometimes people focus just on the code, but it is really all about that collaboration, how people work together. I think at the heart of DevOps really what it’s trying to get at is building bridges, getting people to work together even if they are in slightly different spaces, whether you know it’s DevOps COPs who are trying to bring security practitioners closer to developers or ops people closer to developers. I think open source really captures that spirit of collaboration and that’s why it’s become almost synonymous with DevOps. 

    Shimel: Kevin, Alon, what do you think? 

    Dunne: Yeah, I mean I would definitely agree with that. I would say one other thing that you know of the many benefits of open source, right, is kind of just the transparency and visibility. I think you know a lot of companies were finding like DevOps in the CI/COVID process especially is kind of integral to business success, right? So a lot of companies are very hesitant to put a tool in place that is going to be that critical to their success unless they’re able to you know fully understand what it does, you know any limitations that it has, you know extended where needed and you know kind of have that ability to build on top of it as well.

    I think way too many companies kind of got burnt a bit by you know solutions that were completely closed source, didn’t allow customization and things like that. Then you know they kind of get stuck when you know something breaks. So they reach the limits and the vendor is not able to you know update that for them. So I think that was one of the big things about you know the whole Jenkins’ community, right, as you just see how many plug-ins and other you know ways people come up with of extending the tool that you just would never see from a closed-source product, right. So I think that’s been something as well as just kind of like the ability to have the transparency into how something works and be able to extend that to fit your own needs is pretty critical to DevOps success I think. 

    Shimel: Yeah, I, I agree. Alon, you more than I think even Tracy and Kevin I mean you built a business with a successful exit on an open-source kind of business model if you will. You know what’s your view on… Is, can, is it a chicken and egg? Can you have DevOps without open source?

    Girmonsky: I think if we go back even in more than a decade there was open source and there were commercial offerings, right? There was an inherent conflict between the two. 

    I think that if you fast forward for today it’s about product market fit. I think open source needs to be part of any product as long as it involves developers, maybe even more than developers, but developers as Kevin kind of mentioned we talked about transparency I think developers need to have control. They cannot rely on someone else to have a black box. So anything from transparency, having control, not having dependency. You know if you think about speed to market the more control you have your ability to change quickly you know the faster you can go.

    So what we’ve learned over you know the past decade the developers they need to have the open source not because it’s free. I think that’s the last aspect of open source. It was in the past it was free and a poor man’s solution. Today you want to have open source because you want to maintain control, visibility, transparency and reduce the dependency on other vendors. That’s kind of my key learnings you know from my experience. 

    Shimel: Yeah. I mean that reminds me of something I’ve always been taught and heard about open source and that is look with open source it’s free as in freedom and free as in beer, right? It doesn’t cost, it’s free as in beer, right, free beer for everyone. But really though that was a big driver, you’re right Alon that was a huge driver and remains a huge driver that people can just pick up this software and run with it. And if at some point they want to buy an enterprise license or an enterprise version or go to a vender that has a supported version they can pay for it, but they can use it for free today. But more importantly than that is the freedom as in freedom, right? In that it gives them the transparency, it gives them the ability to see exactly what it is they’re getting themselves into as Kevin pointed out. 

    But to me that’s almost turned the original problem on its face. Tracy you’ve been in these, in this open-source world longer, as long enough, right? In that originally that was also one of the big shortcomings of open source, right, is that everybody, everybody sees the source code, hackers or whoever will more easily exploit that source code or can break in or can see what’s going on. And whom am I going to call, Ghostbusters, right, for support and to fix this thing, right? 

    And so how can I as an enterprise you know based my business on open source? Is it reliable enough, secure enough, supportable enough? But yet we seem to have overcome that. One of the reasons I think, Tracy, is because of the advent of foundations like the CDF, right? So talk about that if you will a little bit. 

    Miranda: Yes, yeah, no absolutely. Like I think well first of all I want to make it clear like you can still have DevOps with a proprietary CI/CD stack and there’s plenty of offerings out there. But I think the key thing where open source plays a big role is it’s really in driving the innovation across the industry, making it so people can leverage it in different ways, combine it and get that interoperability to you know produce things that solve their problem. 

    And the way foundations have really helped is dealing with some of the issues or you know sometimes there have been misconceptions with open source, but sometimes they are genuine problems, which you know fall in the gaps of well maybe the developers on the projects want to focus on the code and there are other things we can do across multiple projects to help you know whether it’s focusing on security or focusing on building communities that are diverse. So open-source foundations have just added that extra layer to give the industry confidence that these are trusted projects that are being well sustained and people can rely on them to either build products or use in their own CI/CD stacks and really just kind of push, push things further I a good, positive direction for the whole industry. 

    Shimel: I’m going to comment or not disagree, but I wanted to distinguish and clarify something you said there Tracy and that is yes there are closed source or commercial or whatever you want to call it CI/CD solutions out there. But even they and we report on them at devopsy.kinsta.cloud right, even they rely on open-source integrations, open-source components. 

    I mean you look at Alon with what you’re doing with UP9, with UP9, with what you did in BlazeMeter. Kevin when he talked about the three or four different open-source kind of based tools that Tricentis is doing, they’re all based on open source. When you go under the covers they’re closed source but they’re based on open source, things like Selenium and these kinds of things. 

    So you know even in the CI/CD space and I’m not here to name names, but we know the closed source you know CI/CD players. I don’t think they’re product works well if you didn’t have an open source kind of framework that they plug into. I think it’s especially true in the testing world. I think Alon you’re living proof of that, right? Could you have had a BlazeMeter without having some of those great open source? Kevin all of the projects you mentioned are based on open source, right? Can you have any of them without open source? It’s a real you know … 

    And guys don’t wait for me to ask your name, feel free to jump in here. 

    Dunne: I think it’s a good point. It’s becoming more of the model like Alon was you know mentioning is it’s kind of you stand on the back of giants a lot of times, right? So I think you know you see a lot of the at least in the testing space, right, BlazeMeter, Sauce Labs, BrowswerStack, you know a lot of these bigger companies they’re succeeding by basically doing what you were talking about with the security tools 10, 20 years ago, right? 

    Take an open source community and kind of you know build something on top of that, right, that provides value, but still is kind of using this known currency of this open-source project. I think people like that because you know by the time they get to buying that commercial solution they’ve got a lot of confidence in the open-source components that have reached a you know critical kind of juncture where they’re bought into those tools enough that they’re willing to invest in something you know commercial to help support it and you’re solving real problems, right. 

    You mentioned you know free and open source being free, but you know everyone knows one of the big challenges with open source is just the amount of time that you have to invest a lot of times to customizing it, deploying it, you know patching it, upgrading it, dealing with security concerns. And so you know a lot of these vendors come in and they solve a real problem, but I think it is a little bit of a you can put the cart before the horse, right? 

    The people need to adopt the open-source tool, see that it works, feel the pain of you know what it’s like to manage it on their own and then you know usually graduate to these commercial solutions. I think when people come and try to present the commercial solution upfront without that open-source community you know it kind of fails because you haven’t proven the value yet, right? And it’s a big jump for people to make and that’s you know been a good thing in the market having open source. It’s kind of put the power in the hands of the users that you know users get to call the shots first and the user expects you’re going to give me some value in this open-source tool before you start to charge me an arm and a leg, right? 

    Miranda: I like the analogy, free as in free puppy, so we can have it, but you still have to take care of it, feed it, and keep it from pooping on the carpet. 

    Dunne: Exactly yeah. 

    Girmonsky: Yeah. 

    Dunne: And that takes a lot. 

    Shimel: Alon? 

    Girmonsky: I think I’ve learned a good concept a couple of years ago, kind of the open core concept. It wasn’t there ten years ago, but then you understand okay this is what, what we’ve been doing all along. The ability to open your core, the core of your platform, the core of your offerings. So you know your user will have more flexibility. Maybe the use case is a bit different than what you had in mind initially, right, by having an open core or an open-source project that you’re basing on, right, you allow the users to build their own use cases and then bring value that again the product market fit is in my view better than anything that has close and this is what you can do with it and that’s it. 

    Shimel: Agreed. So Tracy you know the CDF is a great model for the kinds of stuff we’re all three of us are talking about, right? You have in essence this four main properties or projects that CDF manages. Each one of them is closely tied to one or more commercial entities that solutions are based upon, right? But yet the community revolves around the CDF. By the way it’s the same thing in the CNCF, right, where you have Kubernetes and you have you know a lot of Kubernetes service providers that manage Kubernetes, but the community lives around CDF. 

    What are you seeing here? Like where is that handoff? Where is the you know passing the baton from that open-source user to the commercial entity? 

    Miranda: Yeah, no I think that’s a great question. What we see, well certainly what I’ve seen over the last 15 years is it’s an ever-changing line if you like. So when we talk about innovation you know we have these open-source projects and we don’t want people to be reinventing the wheel over and over again. Like take something like pipeline orchestration. You know when it gets to a point where that’s pretty ubiquitous then that’s a good thing to have as an open source you know kind of standardized in one project. 

    Then we can move up the stack into new innovations and vendors can lead that charge of take open-source projects and try to build things on top of that that add new things to the industry. As those become more and more ubiquitous then you know it probably eventually will get an open-source solution and then people will sort of move onto the next thing. 

    So I think it’s always kind of this tide as such where the more kind of proprietary things will test out the beating edge and where they can get value for using some things that haven’t been done and then open-source projects become like the infrastructure, the roads, and the bridges and things like that. 

    Shimel: Fair, guys any comment on that?

    Dunne: Yeah I think that’s true. It’s kind of tough though puts vendors in a tough position, right, where it’s like you know you have to – it really raises the bar, right on delivering innovation, right, because you know all of the… It’s kind of a commoditization, right, that you know things that have been in the market for 10, 20 years you know the market, the commercial market for those sort of erodes and you know it gets replaced by open-source tools. And so it’s always kind of playing that game of being the you know next hand-up on the baseball bat. 

    You know it’s just like your always – if you stop innovating there’s… I think that’s why you see you know the SAS model being really popular with a lot of these software companies is just they need to keep innovating, right, and you can’t just like you know expect to sell a tool, a licensed tool and you know have a customer use that for ten years and collect maintenance from them. Like these are – all the tools that are you know demanding good budget from companies are really you know evolving quite quickly. So it’s really put a lot of pressure on vendors to innovate, otherwise they’re going to become stale and replaced by open source pretty quickly, which is a good thing for the uses of these tools I think at the end of the day. 

    Shimel: I also think that’s to Alon’s point that’s why OpenCore is such a great model for this, right?

    Dunne: Yep. 

    Shimel: Because you can’t – you can keep innovating at your core and then have your freemium, premium, whatever you want to call feature set kind of revolving around that core and keeping people, “Okay now that’s why I should pay money.” 

    Dunne: Right. 

    Shimel: So –

    Miranda: And I think –

    Shimel: Go Tracy. 

    Miranda: And I think we’ll increasingly see companies kind of use that to change the dynamic in the market and then they can use open source almost as a weapon to drive commoditization by saying, “Okay well this thing that was a premium feature for a number of vendors, we’re going to open source our vision” and you know suddenly change the dynamics. So it is real interesting because, yes, I think SAS services will make a big difference and everybody in the industry has to be on their toes constantly. 

    Girmonsky: Absolutely. By the way a way to compliment this is think of you know we used to live in an industry where the big vendors provide point tools, value, do something that you haven’t done before. Today, with developers it’s very hard to think of having an infrastructure that is not open source, right? So let’s assume the entire infrastructure is open source whether by vendors, by developers, or by big cloud like you know Netflix, Amazon and others. Then the next layer is efficiency and productivity. Then the commercial vendors they can provide impact by, you know, this is what I have done in BlazeMeter. It wasn’t — BlazeMeter wasn’t a load-testing tool. I think Flood was the same. It’s JMeter was the testing tool. 

    Dunne: Yep. 

    Girmonsky: BlazeMeter back then was all about making JMeter more efficient and the developers more productive. So suddenly LoadRunner wasn’t like, okay there is an alternative to what was de facto commercial tool, okay it’s the open-source tool, but as you said open  source on its own it’s pretty tough. So you know here come the vendors that make our lives more productive and use of open source more efficiently. 

    Shimel: Agreed. Kevin, Alon I’m going to put guys on a hot seat here for a second. You know what CNCF has been wildly successful in so many of the projects that they’ve incubated and now graduated and have been tremendous successes. Tracy, CDF is only what about two years old now? 

    Miranda: Yeah, not even. 

    Shimel: Yep, they’ve got four pretty amazing CD tools that are kind of de factor standards, right, that people are gravitating around. With such a strong heritage of open source and testing and continuous testing, automation, why haven’t we seen sort of the equivalent of the CDF in the testing world? Right? Why hasn’t the Linux Foundation or some other, Eclipse or Cloud Foundry or something or a new one sprung up that says, “Hey, we’re going to take these individual projects you know out of hands of individual company and do a community thing”? It may be a case of what, don’t break what’s, don’t fix what’s not broken, right, because it seems to be working the way it is. But why don’t we see a foundation for open-source testing? 

    Dunne: That’s a good question. I mean I think you know if I had to guess the main reason probably is just that you know testers are sort of developers, but sort of testers, right, and like an automated tester kind of falls in between the gap of maybe both and some view themselves as developers, some view themselves as testers. 

    I feel like it’s starting to happen. If you look at some of these tools like Cypress for example. You know the newer tools that are emerging definitely they’re communities have much more of like a developer feel around them and there’s much more structures of the open source contributions and whatnot. 

    But you know historically it was definitely very fragmented and you know the load testers all kind of rallied around JMeter and Gatling and you know the web testers around Selenium and the mobile testers around Appium. There’s really no common thread. I guess it’s kind of more like more siloed, right, versus my guess would be you know these tools like Kubernetes and you know Spinnaker or Jenkins, I mean those are ubiquitous, right? I mean everyone whether they’re building you know a web app you know in Java or in you know C# or whatever can use these tools versus I think a lot of the testing tools because they’re kind of like a thought you know into the decision that’s made after you make some decisions oftentimes on your kind of app infrastructure. That’s why they’re sort of thought of as maybe – they were historically thought of as more of an afterthought and the communities got more fragmented as a result of that. 

    But I think that is starting to change. I mean we know and we talked about these results on the last time I was on with you, Alan, you know that testers are becoming more and more like developers and becoming more technical, right? So I think the tools you know are going to demand to change this community structure, but it will take time but I think we’ll start to see that over the next few years my guess. 

    Shimel: Alon?

    Girmonsky: Yeah I think that if you look at the industry, the open-source industry for past second decade you know prior to CNCF there as Apache, right. 

    Shimel: Yeah.

    Girmonsky: Yeah and it was kind of you know in many ways the collection of open-source tools that if you’re in Apache open-source tool you’re probably in good. And now we see it’s not about open sources, it’s about what you do. Right? CNCF started mostly as Kubernetes and you know other tool and now the CD Foundation I think the focus is kind of all you know on the development lifecycle, as opposed to point tools and use cases it’s about the entire flow. 

    Actually I feel very comfortable. You know if testing finds its right position under CD because in CD you build, you test, right, these are the operations you do day-in-day-out. I would hesitate from having too many because it will kind of defocus many people, “I may do this,” “I may do that,” “Is it different?” Having like you know a family to belong to which is the continuous delivery continues deployment maybe in the future. I think it’s actually you know not a bad direction to take. 

    Miranda: Yes, absolutely and I think you’ve hit spot-on like CD continues deliveries is a process and I think that process does include testing and although we started off with these tools, which are all pipeline orchestration I’d love to you know CDF to future more open-source testing tools and certainly a lot of the conversations we have around interoperability testing comes up a lot. You know people are like, “Why isn’t there a standardized way to show pipeline results, the test runs” and why don’t we strive for that? That’s you know a problem that lots of end users highlight. So yeah, I’m all for you know having CDF be a place where we can have more of the testing community come together, seed, expand beyond kind of the traditional developer or and just make folks feel included in that community. So yeah, we should definitely talk. I like the direction [crosstalk]. 

    Shimel: So you heard, you heard it here first on DevOps Unbound. Alon, Kevin you have her contact info. 

    Dunne: Oh yeah. 

    Shimel: Let’s see some testing projects being part of CDF, right? Let’s bring it together. 

    Alon, the next line of questioning starts with you, but Kevin and Tracy feel free to jump in. So Alon you’ve been there, done that, you did BlazeMeter as you mentioned. You build it on JMeter and some other open-source stuff, but you didn’t want to duplicate what JMeter did, you were supplementing it and building on top of it. 

    Your present company, UP9 is new, not a lot of people are as obviously familiar with it as BlazeMeter. But I remember interviewing you when we first started talking about UP9 and you said, “Look this is for now, right, this isn’t what BlazeMeter…you know we took a lot of lessons that we learned and a lot of things that we saw, but this is for today.” What makes it for today, especially from an open-source perspective, right, that was different than when let’s say BlazeMeter you know first started with JMeter. 

    Girmonsky: Yeah. So BlazeMeter dealt with a problem that was irrelevant for 2010 or 2012, it was again it was kind of moving to the cloud, the Web-scale system, but mostly around service oriented architecture, right, and WebUp monolith of the time. At this time let’s say 2020 and going forward we’re talking about cloud native and containerized system. The industry took an approach to build the system that scales horizontally, right, with microservices. When you have than a few microservices you bring in Kubernetes or Docker Swarm or ECS sometimes, right, to orchestrate. 

    But this entire new tech stack it is far more complex than it was n the past and still you need to test. You have you know you call it not reliability, you have to have reliability case. You know you develop software you don’t want to develop faults that become failures, right? So and again it’s far more scalable in the past. If we used to do one service, now we have 200 services, dependencies, individual roadmaps, what do you do? 

    So UP9 takes care of it. UP9 provides a way to first test each and all microservices, like to provide the complete test coverage, but also do it you know use machine learning to offload a lot of the work from the developers. 

    Now to connect this with open source again I’m a strong believer that it’s not this or that, it has to be both. You have to start with open source because you first need to onboard your users, right? The only way to onboard them for them to have confidence is by giving them open-source tools and not because it’s free or because I want to make a name for myself in the open-source community, because that’s the only way to start you know the operation and then you make their lives, the developers’ lives more efficient.

    So this is UP9, UP9 start with open core solution that enables testing microservices in a Kubernetes ECS Docker kind of environment, but making it no matter how many services you may have, how many endpoints, whether it’s thousands of endpoints and hundreds of services you know you get things going pretty quickly, because you know this is how you would do things these days. 

    Shimel: Understood. Kevin, Tricentis I mean Alon’s example applies directly to Tricentis, right? You have three or four projects that you’ve spoken about, acquisitions that you manage, you know you’re managing these open-source communities and project, but yet there’s, you know there’s commercial or closed-source Tricentis. Where is the integration, where’s the overlap, where’s the leverage from one to the other? 

    Dunne: Yeah it’s a good question. I mean I think we’re kind of starting to see two different I would say maybe like communities of practice you know coming out of large IT organizations, right? You have definitely what Alon was talking about which is like kind of people building these I would call “systems of engagement,” right, which are customer-facing apps, that you know have all of these challenges around how to deal with containerization. So that’s where we really target a lot of our open-source tools, right, and open-source friend tools so that those people who really developing these web apps, mobile apps, you know web services in-house. But we’re also seeing that you know there’s this other large community as well, which is kind of all the systems of record, which should be maybe your main-frame systems, your package apps, like SAP, Salesforce, you know Workday. 

    And some of those communities, like some companies are starting to really start to try to do CI/CD and things like that around Salesforce and some of these more cloud-friendly apps, but for the most part a lot of those communities that kind of work differently they have different expectations, they usually are less technical and a lot of times would actually prefer sometimes a closed-source tool to kind of match the closed-source ecosystem that they’re supporting. 

    So that’s where I think you know when you look at it you kind of wonder, “Well hey how, why does Tricentis have both closed-source and open-source tools?” But I think you’ve got to have the right tool for the job and the right tool for the user, right? And so we see that you know you can-to-go and bring a highly technical tool to you know a nontechnical user that’s trying to test you know a very legacy package application. And vice versa you can’t bring you know a commercial tool a lot of times to a developer that wants to be you know able to write code and you know implement it into their DevOps pipeline and things like that and force them to take that approach. So rather than trying to you know have one or the other group suffer we’re sort of trying to bring together a platform which provides you know different tools for the different approaches. 

    Shimel: Tracy how does that jive with what you see with some of the pipeline tools and projects and companies in the CI/CD world with CDF?

    Miranda: Yep, no I think it’s really interesting and it was great to hear that distinction. So when look at cloud native and particularly Kubernetes and things sitting on top of that, I think the state is today that you still have to be highly technical to stitch a system together and to make it work and to keep up with all the updates. So it’s far, far away from being used very effectively by folks who are less technical or folks who want to be a bit more removed and just get a certain job done, but still take advantage of you know all the benefits of these containerized cloud-native systems. 

    So I think where the open source has to evolve there is to make that a lot easier. We talk a lot about kind of the developer experience and what that looks likes, because today like it’s really confusing if you had to come in new and figure out you know what tool to start with, how to put it together, take Kubernetes itself it’s got hundreds of distributions, which one do you even start? And then there’s a lot of confusing information as well for how you make decisions. 

    I think there’s a lot we can do in open source to drive some clarity on you know what are you trying to achieve, how do you get there, and how do you make the tools work together effectively and not leave it as an exercise to the user to figure out what goes with what. 

    Shimel: Agreed, agreed. Guys were coming … You know I could sit and talk about this with the three of you for the rest of the day, but we’re coming up on 45 minutes, which is kind of our cutoff here. Tracy you’ve heard what Alon and Kevin have said. So first of all guys I’m going to hold it to you. I’d like to see you reach out to Tracy and start and I’ll help, I’ll introduce some of my other friends in the open source and testing world and you have my commitment Tracy on that. I’ll do an e-mail intro. I’d love to see some testing projects become part of CDF. I’d like to see it expand beyond the pipelines to the real tools that folks are using in these things. 

    But you know Tracy CDF as you mentioned is less than two years old. We just last week we had KubeCon CNCF, Virtual Con, whatever I think it was called, what’s in store for CDF? What should our listeners be looking for? 

    Miranda: Yes, yeah, no, we are having our first big cdCon which will be virtual. It’s a first stand-alone event we have for bringing all the communities together. Because of COVID you know we’ve had to pivot quickly to going virtual. So you know it’s not going to be the same as in person, but it is going to be a really good way to bring people together and get that interaction. 

    So cdCon which October 7th and 8th and registrations are open now. That will be yeah just a really good way to come in and figure out what is the state of continuous delivery today and lots of different tracks on specialist topics and cloud native and of course lots and lots of open source. 

    Shimel: Don’t miss it. So that cdCon, October 7th and 8th, highly, highly recommend it. I’m sorry my Apple watch was ringing. There we had to shut that off quick. 

    Thanks Tracy. People can get information at that at CDF? 

    Miranda: Yes, as cd.foundation and find details there.

    Shimel: Great. Kevin, news around Tricentis open-source projects and products. 

    Dunne: Yep, yeah. I think for us you know like Tracy mentioned we’ve got to go virtual this fall as well, but we’re having our annual Accelerate conference this time online. We had one that was focused in kind of May on more of the US area, but we’re having more of a global one to come in October. So we’re going to be showing off a lot of exciting new stuff about a lot of the tools that I mentioned like test projects, SpecFlow, Flood. A lot of new integrations kind of between those tools and the core platforms. So starting to develop that story that I mentioned about sort of one platform to fit various different approaches, whether that’s more of the technical users or the nontechnical users. So that’s definitely one to check out. I’m just checking the date. I think it’s the 21st and 22nd of October is when we’re planning that for it I believe.  

    Shimel: It’s going to be a crazy October of virtual events. Alon, how about you and UP9?

    Girmonsky: Yeah, you know and the UP9 is a new startup. We started almost two years ago, but we are working diligently to complete our software. We already released our first version, but you know the work, still a lot of work ahead of us. So I hope to show you a lot of new cool things down the road. Now we are heads down you know building and building. 

    Shimel: Excellent. Guys I want to thank all three of you for being on DevOps Unbound with us today. I wish we had more time to dive into this. You know there’s so much. Even the idea of having a CDF versus let’s say five or 10 years ago if I told you we were going to have something called a “CDF” you wouldn’t believe me, right? You would think, “What do we need this for?” And you know so we’ve come so far in DevOps and continuous delivery and Kubernetes and — well Kubernetes itself is open source, but this whole revolution honestly around open source and community it’s what makes, it fuels so much of what we are seeing. You know where would we be in COVID without a lot of what we’ve, open source has enabled us to do you know using technology? So I do think it is, it is an integral, it’s a precursor to having the DevOps world that we live in today is open-source software. 

    So, thanks for joining us. We have to have you back on. I’m serious about testing tools in CDF though guys. I think that’s some, long, long overdue. Tracy, thank you and best of luck now that you’ve moved fulltime into the CDF. I know you’ll make great things happen there. Kevin, Alon, best of luck to both of your companies, UP9 and Tricentis. This is Alan Shimel for MediaOps, devopsy.kinsta.cloud. Thank you all. Thank you for watching. We’ll see you on the next DevOps Unbound, soon. Bye-bye everyone.

  • DevOps Chats: Liquibase, Open Source and Databases, with Datical

    DevOps Chats: Liquibase, Open Source and Databases, with Datical

    Datical has been a leader in DevOps for databases since even before the term was used. What many may not realize was that the open source Liquibase project was a major contributor to Datical’s success. So it should be no surprise that in filling the open president’s seat, they would tap an open source veteran.

    Dion Cornett, has open source credibility from his time at Red Hat and MariaDB. In his new role, he is responsible for marketing, sales and product. He is determined to see the same kind of success with open source business models he has been part of before, succeed at Datical.

    In this discussion we hear from Dion on his plans and views.

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

    [soundcloud url=”https://api.soundcloud.com/tracks/771223528″ params=”color=#ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true” width=”100%” height=”166″ iframe=”true” /]

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel for devopsy.kinsta.cloud. You’re listening to another DevOps Chat. We’ve got a nice DevOps Chat for you today, happy to introduce you to the newly minted president at Datical, Dion Cornett. Dion, I didn’t mess that up, did I?

    Dion Cornett: You didn’t, and thank you very much for the introduction, and I’m very happy to be on your podcast today.

    Shimel: Thank you, Dion. So, listeners of our podcast are no strangers to Datical. You know CTO Rob Reeves is a frequent guest here, and you know, we make fun of him and his Big Lebowski sweaters, but it’s always refreshing to hear Robert’s take on DevOps and databases, the DevOps market in general, and pontificating on anything Robert likes to pontificate about.

    But it’s also nice to have a fresh face from Datical. So, first of all, welcome aboard.

    Cornett: Thank you.

    Shimel: And I always like to give my audience a flavor for who’s talking. Dion, would you mind—I’m not asking you to read your bio, but would you share a little bit of your background for the audience?

    Cornett: Yeah, you know, I think what is more pertinent to Datical, I’d say if I had to characterize myself as that, I’m an open source guy. I bleed open source, I believe it’s a better production model for software, you know, this combination of a meritocracy of ideas and transparency leads to more elegant code.

    And so, you know, my background has been one of sort of having a career that aligns with this philosophy. So, I spent nine years at Red Hat in a couple different executive roles, run North American non-named account sales, and then ran global strategic alliances. I moved from there to take over sales at MariaDB, an open source database company that was—

    Shimel: Sure, [Cross talk] well.

    Cornett: Yeah. [Laughter] It wasn’t quite so popular in 2013, but we literally grew that business sevenfold in three years. That set me up for a CEO job. I did do something outside open source, but it was sort of a big data challenge, a company called ReachForce, that we successfully sold to another company in this space called Leadspace.

    And then, I was actually taking some time off, and introduction through a board member, spent some time with Datical, and just sort of fell in love with the concept. So, you know, my work at Red Hat, which obviously covers the very foundations of sort of IT into all the challenges as it relates to data at MariaDB and really sort of seeing the struggles that go on in building and maintaining a big, powerful database and how central that is to virtually any application. And you look at some of the top banking or telecom type customers we have, you know, data is the core of some of the value that many of these companies create.

    And then, even at ReachForce, right, big data company in the martech space, data is just paramount. It’s all maintained in databases and trying to update, upgrade, you know, maintain those databases in the context of fast changing application requirements is a non-trivial exercise.

    And so, when a company came along that had this combination of the open source that’s sort of in my DNA, and then solving this challenge around database change management, it just seemed like a great fit.

    Shimel: Absolutely. So, you know, another thing let us get out of the way early on, Dion, is—in today’s world, when we appoint a president, you know, there was a time, as we were talking, CEO and president were one person. And then, from a governance point of view, that’s a bad model. We have, for the most part, split off CEO from president. And presidents have various responsibilities. Some are more of a COO, some are more of a CRO, you know, meaning responsible for all revenue kind of activities.

    Just, what—where is your, you know, what are you responsible for at Datical?

    Cornett: Yeah, so, formally, my responsibilities are sales, marketing and product. And sort of the genesis here, and I have a great relationship with Derek, the CEO of the company. We’ve been on the job for a month now and I think we’ve teamed well, even through my recruitment process and through that.

    But Derek has built an amazing culture here. And this is one of the things you never know when you start a new job is just sorta, you know, what is the synergies between the team, and Derek’s a very effective leader, he’s built a great culture. In terms of the depth and the value of the solution that Datical has, it’s sort of undisputed, right? We’ve got multiple high six figure customers and even a seven figure customer. I mean, these are solving demanding problems in big enterprises, and the company’s been very good at that.

    I was brought on for a very specific charter, right? How do we better engage and collaborate with our community to push innovation out to the market faster? And as your listeners may know, Alan, the real foundation for Datical is an open source project called Liquibase. Liquibase is—and one of the things I also did at Red Hat was, I ran the venture portfolio there. I’ve looked at literally hundreds of open source business plans, made a dozen plus investments and sat on a few boards of companies that Red Hat invested in. And Datical was sort of a top 10—or Liquibase was sort of a top 10 project as you look at the thousands and thousands of open source projects.

    And so, how do we work with that community, again, in a collaborative fashion that we’re really pulling innovation, pushing it back, and driving as much value into this challenging database problem as we can?

    Shimel: Absolutely. So, you said a lot, there. Let’s pick ‘em off one by one.

    So, first of all Liquibase. It’s something we’ve mentioned in past podcasts and in past content type webinars and stuff that we’ve done with Datical. But—and maybe you’re gonna change this, and I hope you will, Dion. I know in my mind, when I think of Datical, I don’t think Liquibase. And though Liquibase has a tremendous following, I just don’t—it seems like, and I’m not blaming anyone or anything like that, but I just, I don’t connect the two. And maybe that’s part of what your mission needs to be.

    Cornett: Absolutely. We want this connection to not only exist, but be robust. Again, we’ve got a great team here, great culture, great people. We wanna use that to be excellent stewards of the community.

    You know, part of what motivates people here is, this is a big challenge to solve. You sort of commented earlier about sort of the maverick kinda style that Robert has, and I think it’s properly so, right? We’re breaking some glass. We’re trying to create a new mold, a new direction for how and a very important development of how IT operates.

    And so, that’s Liquibase. And, you know, Datical is a set of capabilities built on top of that. We need to make it clear, though, that that core is our foundation, and that, you know, we wanna be, again, as good of stewards as we can of that Liquibase community, 15 million plus users, and you will see this become much more of our identity, in everything we do, how we act, behave, where we invest and what we do to try to push value forward into our customers.

    Shimel: Excellent. So, Dion, let me throw another thing along the open source stuff out at you. You know, as I spoke to you earlier, I have my own views of where the market is, you know, builders, the democratization of IT, as I call it.

    I also have a view of where the open source movement, you know, the whole open source community is. And that is, you know, we’ve moved from the cathedral and the bazaar to what I call the big brother stage of open source where, seemingly, every open source project was kinda sponsored or in fact owned by a single vendor. And that kind of inhibits collaboration on an industry basis, right? It’s like, Oracle wasn’t gonna contribute to MS SQL. I mean, MS SQL was far from open. [Laughter]

    But let’s say, once Oracle bought—

    Cornett: MySQL.

    Shimel: MySQL. Look, that was the reason Maria and a host of others popped up, right? Because people weren’t sure that Oracle was gonna play nice, frankly.

    But that’s old. The model is what I call the foundational era of open source, where we have, like, the Linux Foundation or the Eclipse Foundation or the Cloud Foundry Foundation. You know, they’re these not-for-profits that are, they quote-unquote own the open source project to the community’s benefit.

    I’m not aware of a foundation in, like, the Liquibase kind of playing field. Are you, or is that—

    Cornett: No, you know, and I’m very familiar with the foundation model. Yeah, obviously, Red Hat was sort of a pioneer in this with Fedora.

    Shimel: Sure, yeah.

    Cornett: And we actually implemented a foundation model at MariaDB as well. And so, even if you look today, MariaDB.org is a separate legal entity—

    Shimel: Yep.

    Cornett: Separate president and set of engineers. And the real purpose there is to provide confidence to the users that, regardless of vendor acquisitions as you discussed, that the capabilities of that project will go forward.

    And we don’t—again, I’m a month on the job here—we don’t have a foundation today with Liquibase.

    Shimel: Right, I’m not asking you to—don’t say anything you can’t [Cross talk]. [Laughter]

    Cornett: Yeah. [Laughter] It’s certainly a consideration. [Cross talk] But it’s, you know, it’s a measured one, right? So, what are the trade-offs, what are the value? And as you talked about the different phases of open source, I think it’s—it’s unfortunate that there was a point where open source was sort of a, you used the phrase democratization of technology; that was a phrase also used by Matthew Szulik, the former CEO of Red Hat.

    Shimel: Uh huh.

    Cornett: And he also talked about this fashion statement thing where people, open source is a success. I mean, everything you use on the Internet, IT today is open source for the most part. So, it’s clearly won, right? That battle’s sort of over, and people said, “Hey, I wanna glom onto this.”

    And so, there was sort of a group of companies that attempted to co-opt the branding around open source without really understanding the nuance of what it meant to be a steward of the community and collaborate well. And in some ways, I think that sort of provided a skewed vision. And we’ll avoid that at Datical. You know, again, we’re gonna be good stewards of the community. We recognize that it’s gotta be participatory. Most of the community members are people that have jobs at companies you would recognize in IBM or SAP or other places like that. And they’re taking time to be part of this community, because it provides some value to what they’re doing and their professional life.

    And so, we’ve gotta recognize that we have to contribute to that value, attempt to sort of usurp what they’ve done, and go off and monetize it without the, never work, because if it really is important functionality, someone will just do a fork and monetize that around.

    It’s really about providing these synergies—and I used this phrase earlier where you have a meritocracy of ideas and that sorta lifts everyone up, right? So, we can provide higher value to customers that need the specifics of an enterprise offering or as we have brands, as you say, Liquibase Pro. And then the people that are, they’re part of the community for their specific needs that they’re getting multiples of return also on that investment for the problems they’re trying to solve.

    And it really is sort of this, community is the perfect word for it, because it really is this joint effort to make everyone better off.

    Shimel: Great. Dion, we’re running out of time. I wanted to give you one more thing to chew on. I want you, in your mind, to fast forward six months, 12 months, take your pick—what effect have you had on Datical?

    Cornett: You know, I think that we have to look at—so, part of what we’re doing is, we’re taking a blank sheet and we’re saying, hey, if we were gonna start today and look at the trends in the market, cloud, microservices, NoSQL, NewSQL, you know, these are all things that weren’t necessarily the case when Liquibase was originally founded by Nathan 10 years ago, what would it look like today versus where we are? And where are the gaps between the perfect DevOps solution for database and what we have in the community today, and sort of how do we help guide and steward that into a place that really solves the problem that we’re facing and we’re going to face as the IT infrastructure continues to evolve?

    And so, I think, if we can look back in a couple years and say, “Look, this has been the evolution of the product, and it’s much easier to use, it’s much easier to implement, the time to value is relatively quick,” and it’s really allowing, at the end of the day here, we’re trying to let database keep up with all of the DevOps advances that have been made around the application. If we see the database not being the drag on application, timeliness, speed, effectiveness that it can be today, then I know we’ve been successful in sort of this re-instillment, re-engagement in the community, and pushing that innovation into the product.

    Shimel: Yep. I agree with you. Dion, I promised I’d get you out of here in 15 minutes. I know you have another appointment. But I want to invite you back. Maybe we’ll do a video next time and we can dig in a little deeper. And, you know, I love talking about open source, as do you, it appears, and our audience does, too.

    Cornett: [Laughter]

    Shimel: So, I think it’s a great topic for us to continue. I wanted to wish you all the success in the world, though, with Datical. It’s a great bunch of folks over there, and you’re a great addition to the team.

    Cornett: Oh, thank you very much. I appreciate the kind words, Alan. And yeah, I look forward to future conversations. It’d be great.

    Shimel: It certainly well. Alright, Dion Cornett, new president at Datical, joining us here on DevOps Chat. This is Alan Shimel, and you’ve just listened to another DevOps Chat. Have a good day, everyone.

    — Alan Shimel

  • DevOps Chats: Solving Complexity in Continuous Testing, with Sauce Labs

    DevOps Chats: Solving Complexity in Continuous Testing, with Sauce Labs

    SauceCon 2020 by the good folks at Sauce Labs is just about a month and half away (April 27). As part of our lead-up to the show and our coverage including live broadcasting on Digital Anarchist, we caught up with newly minted Chief Product Officer, Matt Wyman.

    Matt discusses how continuous testing, automation and DevOps has led to better testing. With that though, we are more complex and sophisticated than ever in how, what and when we test. Can’t we just keep it simple? Do we want to keep it simple? Have a listen to what Matt has to say, as well as why he is so excited about this coming event.

    If you are interested in testing at all, do check out the great lineup for SauceCon. Hope to see you there.

    [soundcloud url=”https://api.soundcloud.com/tracks/770790922″ params=”color=#ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true” width=”100%” height=”166″ iframe=”true” /]

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat is meant to give you a little bit of a flavor, a preview for the upcoming SauceCon put on by Sauce Labs, which will be at the end of April. So, about a month and a half away, almost two months—well, a little less than two months away. It promises to be another great event from the folks at Sauce, and they have, really, just a packed lineup of speakers from a wide range of enterprises and startups and tech companies, manufacturing companies. I mean, just a whole gamut.

    Anyway, speaking with me today about SauceCon, about maybe some new developments and trends in the testing market is Matt Wyman. Matt is chief product officer at Sauce. And Matt, welcome.

    Matt Wyman: Thank you. Glad to be here.

    Shimel: My pleasure. So, Matt, let’s get this out of the way first. You recently joined Sauce in, like, January, correct?

    Wyman: I did, January 6th. I am a recent addition to Sauce Labs, and very excited to be here. I’ve been in the DevOps community for some time, worked as the head of product for CircleCI, so definitely a space that I know well.

    Shimel: Sure

    Wyman: But I see this massive opportunity and impact around test, and this fragmented space, and hopefully, we’ll get into this and talk about complexity a little bit. But it just really seems like a huge opportunity and a company that I love and a great reputation, so I’m excited to be here.

    Shimel: Very cool. You know what’s interesting? I mean, of course, CircleCI is in and of itself a great company, too. We’ve—you know, I’ve done a couple podcasts with Rob, the CTO over there.

    Wyman: Yep.

    Shimel: And, you know, they recently, they raised a bunch of money, they’re really becoming a player in the CI/CD space. But it’s interesting that you moved from CI and CD to testing here, and you know, when we look at, let’s say, CloudBees, right, and Jenkins, the Jenkins founder, KK, you know—I’m not even try to pronounce his name; let’s just call him KK. But anyway, KK recently left CloudBees and the Jenkins community to start a new company also focused in the testing space.

    So, I think your move here, KK’s move—I think it shows that, as the whole CI/CD, you know, software delivery pipeline type of industry and community matures, people are recognizing that testing is kinda where it’s at right now, right? That’s the new battleground. And maybe it is, as you mentioned, Matt, because you know, the mission has grown so much more complex than, you know, let’s say pre-DevOps, right?

    Wyman: Absolutely.

    Shimel: So, why don’t you—if you don’t mind, give me or give our audience an idea of where you see or how you see testing has become, you know, more complex.

    Wyman: Absolutely. So, speaking to the CI/CD platforms just for a moment, orchestration in CI/CD has become a very complex problem, and that’s reflective of changes in the software landscape and how people build software, which itself is a reaction to where we started.

    So, we had all these monoliths, these, you know, large systems, we’ve all talked about it, they still exist out there in the world. Most every system that says that they do microservices actually has a monolith somewhere, like, micro-monoliths all around.

    When you’re in the monolith world, testing is all about end-to-end testing. You’re trying to put all the pieces together, validate that everything works top to bottom, and that’s really where quality and test have their roots. And as much as possible, it’s all about trying to automate those difficult processes and make it easier and more efficient to move through all your different test cases.

    But as those entities split up, and as we started to recognize that each component of a larger application needed different types of tests, testing itself became more complicated. And furthermore, it became more than just clicking buttons. At one point, testing was about validation, that if you click a button, you go to the correct page. If you click a button, the right business logic executed.

    But these days, it’s a lot more than that. It’s also validating that the CSS is correct, that the experience is performant and is wonderful and delightful. Companies that have bad user interfaces and bad user experiences don’t win.

    And so, you have this testing world that, on the one hand, is trying to move faster, dealing with a more complex software landscape, and on the other hand, is now broadening in the types of tests that are being run, not just functional testing, but also, if you will, delight testing and trying to validate that the user experience, the customer experience is going to be an excellent experience at the end of the day

    Shimel: Yeah.

    Wyman: And so, that’s how I see this space splitting up.

    Shimel: Absolutely. I don’t disagree with you there. You know, Matt, I almost wanna put myself in the shoes of the test professional and the QA person who, you know, maybe six or seven years ago was hearing that DevOps and this move, you know, agile to DevOps and beyond was gonna somehow make them obsolete. And then other people were saying, “Oh, no, it’s not gonna make you obsolete, it’s gonna free you up to do higher level kind of tasks that are more worthy of your talent and skill set.”

    And I think that has come true, certainly. I think what we’ve seen with test automation has freed up testers to do higher level stuff, but I also think it shifted the—not the burden, but the emphasis on people who know how to set up automated testing, right? You’ve gotta know maybe a little bit of coding, a little bit of scripting, you gotta know some of these open source tests.

    Wyman: There’s a bit of all of the above, don’t you think?

    Shimel: Yeah, it is. That’s exactly it.

    Wyman: The—and it’s further complicated by the fact that the number of devices and environments we’re testing on has also fragmented and increased. And you can’t run the same type of test in every environment, so most software applications have some sort of mobile component to them.

    Shimel: Yeah.

    Wyman: And yet, mobile testing is not automated in the same way that you would automate browser testing. And in fact, in some cases with mobile testing, it’s more effective to be manual and to go through it piece by piece, or to use visual testing to go through it.

    And so, you have to pull together all these different techniques. I think there’s often this perception that, with any new technology or any new change, that it’s going to somehow upset the apple cart and suddenly everyone who has a job doesn’t. And it just doesn’t typically work out that way. I think what we’ve seen is just this increasing complexity, and then also the opportunity to use the right type of testing in the right place. Meanwhile, a lot of the people out there doing quality testing continue to do so, because the number of applications has only multiplied.

    You know, the fact this whole digital transformation and all the buzz words that you hear about that—fundamentally, it’s true. Every business is now a software business, and one of my favorite examples recently is, where I live, there’s a highway called 101, a pretty big highway, and there’s a big billboard on the side that has a, it’s from Wells Fargo, and it has a mobile app on it. And the billboard is not advocating or talking about Wells Fargo’s core business, they’re not talking about loans or lending or savings accounts, it’s talking about their mobile app and the experience of their mobile app. And you better believe that they care about testing it, right?

    And so, it’s more than just—again, I covered this earlier, it’s more than just feature function right now. You have—you need more people who need to look across all the different touch points and then utilize the right type of testing in each area. And so, there isn’t one test solution that solves all of it. You have to use different techniques, because ultimately, you’re managing business risk, and you have to do it all the way from the moment a developer checks in code all the way through to production and validate, if you will, a virtual user. Someone has to go validate that it’s actually working as expected when a customer reaches out to interact with the tool.

    Shimel: Yeah, yeah. And, you know, Matt, you hit on a couple—you hit on web testing, mobile testing. I think one of the things, you know, thinking back to when I was running software companies, testing was always something that meant that we were a day late and a dollar short with, you know?

    Wyman: Absolutely.

    Shimel: It seemed like we never had enough budget to do all the testing we thought we should do, and we never had enough time to finish the testing at least we were going to do. But when I look at the kinds of testing and the amount of testing that goes in today, and all of it pre-deployment and everything—yeah, it’s grown more complex, but I think just beyond pure complexity, I mean, would you say we’re testing more now than we did before.

    Wyman: Well, I think part of the answer there is to dig in on what does it mean to test. So, these days, it’s about risk management. And so, if we’re going to have developers able to check in code and 10 minutes later update production, then we’ll need mechanisms to ensure the production is safe. And typically, that’s done with feature flagging, it’s done with canaries. There’s all sorts of ways to ensure that each change doesn’t blow out production.

    But along that path, it’s also about automating as many of the different possible negative outcomes as you can. And that is what we would typically call testing. So, there’s visual testing, there’s browser testing, there’s unit testing, there’s end to end testing, integration testing. All these are necessary, and you’re trying to compress them all into that 10 minute window, which—you know, most organizations can’t hit that kind of number, but that’s the gold mark if you can hit that 10 minutes from change to production.

    And so, I believe that it’s a matter of thinking about risk and saying it’s not about quote-unquote test coverage with a go/no go meeting where you look at the test coverage—and frankly, there’s so much peer pressure to go that typically organizations do. It’s more about saying, “What is the possible negative outcome, and how do I ensure that I have appropriate coverage for each of those negative possibilities?” And in some cases, you’re going to build tests to simply block and fail that particular change, and in other cases, you’re going to provide monitoring and observability to ensure that, if something negative happens, you can pull it back quickly.

    And if I go very meta for a moment and go well above even what Sauce Labs is doing as a platform, I would suggest that all of that is a part of the overall test or risk management perspective. And ultimately, I think our goal is to then create visibility across the whole thing, so you can manage your risk, manage your test all from one place.

    Shimel: Got it. Makes sense. Now, Scott—Matt, excuse me—let’s talk a little bit about SauceCon. How is all of this manifesting itself, you think, at SauceCon?

    Wyman: Well, one of the fun things for me is, this is gonna be my first SauceCon. So, I haven’t had the opportunity to see—

    Shimel: Oh, you never went? Okay.

    Wyman: I’ve never been, so, this is gonna be my first one. I mean, I’ve seen the lineup, it looks fantastic. I’m hoping to see not only a whole series of really good conversations within our existing community, but also, there are quite a few people that are coming who are Selenium, who are Appium users, developers and whatnot, to share in some of their experiences.

    I know, as a product person, one of the conversations I’m very eager to have is in how we help people shift left. And so, it’s more than just running Selenium tests, it’s about the headless tests, it’s about getting earlier upstream so that we can provide a little bit more of a developer oriented experience. And so, I’m very excited to go have those conversations, and I think the lineup looks good to have it.

    Shimel: I agree as well. So, I’ll tell you, my experience is, you know, if you’re looking for conferences around testing and how—like, what’s pushing the frontiers there, right, and also pulling in the open source testing community, SauceCon is one of the best. And I’ll tell you what I like about what Sauce Labs has done there is, you will see other testing companies represented, mentioned, participating, right? I remember, you know, CA who had bought BlazeMeter, for instance, was involved in SauceCon. I don’t know if BlazeMeter will be there this year or not, but they were there. I know the Tricentis folks also like to participate.

    And part of the reason is because testing is such a big world with so many different facets today, you know, everyone kinda does—you know, they’re not necessarily head on competitors. A lot of this is sort of complementary. And so, it’s really nice to see the community come together. You see it a lot—and maybe this is something that is specific to DevOps in general, I don’t know, but you see it a lot at these DevOps events where, yeah, it’s Sauce Labs throwing the party, but the whole testing community partakes. And that, I think, to me is one of the things that makes SauceCon really special.

    The other thing is, is just the speakers. I mean, you know, like in any vendor/user type conference, you’re gonna get the CEO, the CTO, and I’m sure Matt, you’ll do some presentation. But when you look at the speaker lineup here, you know, you have everything from, like, Google kind of engineers to startups to large enterprises, you’re really getting a good 360 degree view.

    Wyman: What excites me is that the way in which we think about this event, we don’t see it as a sales event. We’re not sending salespeople there.

    Shimel: Right.

    Wyman: A number of my product folks will go, because we’re interested in having conversations. The test market overall is fragmented, but it’s fragmented for a good reason, which is, there are a lot of different use cases, a lot of different problems that people are trying to solve, and quite a few of those folks are going to be there, and so, it’s a good chance to have a conversation if you wanna do, if you wanna know more about visual testing, if you wanna know more about how to use headless effectively or deal with the grid.

    So, there’s this opportunity to share that information and share that knowledge, and I think that’s really what we’re aiming for is an environment that’s a practitioner’s environment. It’s [Cross talk].

    Shimel: Yeah, definitely, in years past—in years past, you know, SauceCon, that’s exactly what it’s been, and I think Sauce Labs has done a great job fostering that, right? It’s good stuff, all around.

    We don’t have a lot of time left, but you know, you just joined in January, you’re fairly new, your first SauceCon, you’re getting a handle around product. But do you feel up to giving us a little projection, maybe, of what we’ll see coming out from Sauce Labs over the next, you know, six months?

    Wyman: Well, I don’t wanna give away too much, but we will have something that I expect to be quite exciting, a new beta labs experience that I think people will be able to go get their hands on and play with, something that moves, let’s call it shift left, a bit.

    And we’ll continue to talk a bit about our analytics and in particular, there’s a new report that we are going to be showing. I think some folks may be aware of it already, but it’s relatively new, it’s called Failure Analytics, where we’re able to aggregate all of the different log outputs and provide intelligence and cohorting of different common errors so that, instead of having to hunt through hundreds, potentially, of failures, we will highlight the common problems, which gives developers an easier time of going and fixing things. Also, it makes it a lot easier to debug across large automated test suites.

    So, we’ve got quite a bit that we’ll be showing from a product standpoint, and like I said, there is gonna be a pretty exciting unveil around a beta project that we’re moving forward with.

    Shimel: I think that’s enough of a tease right there. Hey, Matt, you may not know this, but I’ll mention it for our audience—anyone interested in going to SauceCon, it’s actually SauceCon, S-A-U-C-E-C-O-N dot com, and you can go on there and you can still register to attend. I should also mention that our MediaOps, devopsy.kinsta.cloud team will be there under our Digital Anarchist platform. We will be broadcasting live interviews from SauceCon.

    So, if anyone listening is going to be in Austin for the event—hey, come find the Digital Anarchist broadcast booth or me, and we’d love to hear what you have to say and maybe interview you. You never know. So, yeah, please do that, but check out SauceCon.com for more information.

    Matt, before we wrap up, anything else you wanna add?

    Wyman: I think this is great. I appreciate the opportunity to have the conversation.

    Shimel: Well, now that you’re part of Sauce, you know, we’d like—we do these DevOps Chats pretty regularly, so maybe we can have, maybe we’ll do another one even before SauceCon itself.

    I’d like to—you know, I didn’t wanna put you on the spot today, [Laughter] but maybe in the future, I’d like to hear, what are your top three sessions at SauceCon that you’re looking forward to. You don’t have to answer now, though, but I’m gonna give you a chance to do a little digging, but I’m gonna invite you back on in about two weeks and let’s talk about it.

    Wyman: That sounds great. I think it’d be a good idea to, I assume that we’re at the end, here?

    Shimel: Yeah, we’re wrapping up, and you know what, for our next one, Matt, I’m gonna pick three, too. So, folks, there you have it—stay tuned for our next chat with Matt where, between us, we’re gonna highlight his three and my three—

    Wyman: That sounds like fun.

    Shimel: Favorite talks for SauceCon that we’re looking forward to. Sound good?

    Wyman: Alright, sounds great. I look forward to it.

    Shimel: Alright! Hey, Matt, welcome aboard to Sauce Labs, I think—and you already know it, but you joined a great outfit, a great bunch of people there, and looking forward to seeing you in person at SauceCon.

    Wyman: And likewise—thank you.

    Shimel: Okay, and we’re looking forward to seeing you, our listeners, there at SauceCon, but if you can’t make it, do log onto digitalanarchist.live and you can follow along with us from there.

    Until then, this is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chats. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chats: Sumo Logic Continuous Intelligence, with Bruno Kurtic

    DevOps Chats: Sumo Logic Continuous Intelligence, with Bruno Kurtic

    Sumo Logic has been one of the pioneers in DevSecOps and log analysis for many years now. In this DevOps Chats, we speak with Founding VP of Product and Strategy, Bruno Kurtic, about the Sumo Continuous Intelligence Platform and how it is taking security into the next era.

    Have a listen to this DevOps Chats as Bruno explains how Sumo is trying to meet the challenges of keeping up with the speed of business, today.

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

    [soundcloud url=”https://api.soundcloud.com/tracks/764360107″ params=”color=#ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true” width=”100%” height=”166″ iframe=”true” /]

    Transcript

    Alan Shimel: Hi, everyone, it’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat features Bruno Kurtic, Founding VP of Product Management and Strategy over at Sumo Logic. Bruno, welcome to DevOps Chat.

    Bruno Kurtic: Thank you, Alan.

    Shimel: It’s a pleasure to have you here. Bruno, as we were talking off mic, I think our audience is plenty familiar with Sumo Logic, you know, they’ve been one of the—not founding, but one of the building block vendors within the DevOps and DevSecOps kind of movements. But just in case, maybe there are some people who aren’t, do you wanna give us just a quick background?

    Kurtic: Sure. So, Sumo Logic is a cloud based machine data analytics platform. We help customers collect data, telemetry, machine data, infrastructure data, application data from all of their mission critical applications and infrastructure. We process that data and provide them with a scalable and secure technology to deliver operational intelligence, use cases such as monitoring, troubleshooting, root cause analysis, security intelligence use cases such as SIM compliance, threat detection and resolution, and also business intelligence use cases for sort of understanding how their customers are using their digital services, how their products are being adopted and so on and so forth.

    So, that’s essentially what we do. We deliver this as a cloud based service, so it’s SaaS. Our customers essentially tap into our infrastructure, send us the data, and they then get to use their data and get the insights in real time.

    Shimel: And you just joined the company last month?

    Kurtic: No, I’m—

    Shimel: I’m kidding. [Laughter]

    Kurtic: I’m a Founding VP. [Laughter] So, a little bit longer than a month, I’d say maybe two months, maybe close to 10 years—here we go, right?

    Shimel: Close to 10 years. Ten years goes in the blink of an eye, doesn’t it?

    Kurtic: It does, it really does. It’s really astonishing. Sometimes, it feels like a really long time, and sometimes, it’s like it was yesterday, right? And so, it depends on the day.

    Shimel: Unbelievable. Yep. I agree. I’ve been there and done that. The last startup I did before MediaOps, I did nine years, and it just—

    Kurtic: Oh, okay, there you go.

    Shimel: I know how that goes. Anyway—so, Bruno, thank you for joining, thanks for the background. But let’s, I wanted to jump into continuous intelligence, which is, you know, kinda the phrase that Sumo Logic is gathering around. And of course, you know, in DevOps, we have continuous everything, right?

    Kurtic: Yep.

    Shimel: But continuous intelligence—continuous intelligence, excuse me. What do we mean by it? What does it mean in the terms of the way Sumo uses it?

    Kurtic: That’s a great question. And actually, sort of, this whole, the purpose of this platform that we’ve built, it really is to provide the continuous intelligence through a digital enterprise, right? And what we mean by continuous intelligence is the following.

    As you just said a couple seconds ago, in DevOps, everything is continuous, right? You continuously push code to production, you do continuous testing, continuous integration, right? And you’ve got continuous feedback from your application services that you deliver and then you take that feedback into your product development cycle and you continue to improve, right?

    When we talk about continuous intelligence, we recognize and see that in this world of high speed software development and digital economy that the data generated by production application, mission critical applications and services that serve customers and generate revenue—collecting that data is important in real time, and this data is ubiquitously applicable, right? This is not just for DevOps teams to manage the applications, it’s not just for security teams to secure those applications. This data is relevant to the entire digital business, right? It’s useful to product managers to understand how their products and services are being used. It’s useful to sales and marketing teams to understand how the customers and prospects are leveraging their digital services. It’s useful to finance teams to understand how the—what’s the cost, behavior, and other things related to those digital services.

    So, continuous intelligence, it basically refers to this continuous need for data in the business to continue to improve how it operates, how it competes, how it delivers value to the customers, how secure, how to secure those properties and so on, right? So, it’s ubiquitously applying the data that’s generated by the digital services across all those use cases.

    Shimel: Fantastic. You know, an aspect to this and an aspect to a lot of DevOps as well as DevSecOps is automation.

    Kurtic: Yep.

    Shimel: But, you know, Bruno, my time in security, if I learned anything is, sometimes, people don’t embrace automation because they’re afraid of security run amok, right? I’m gonna block the CEO’s email or I’m gonna shut down a critical application or, you know, business process.

    Kurtic: Yep.

    Shimel: So, how do you reconcile, right—and so, it’s one thing to gather intelligence, actionable intelligence, as we used to call it, right, and on a continuous basis make adjustments and stuff, but to really, to move at the speed of business today, you then have to, you almost are forced to automate, right, responses and so forth.

    Kurtic: Right, absolutely. So, you know, you bring a very valid point. Like, you know, my entire career has always been in enterprise software and the last 12, 14 years has been in this specific area of sort of monitoring and troubleshooting security. And it has always been the case that—not just on the security side, that our remediation, you know, people are scared of, it’s also on the operation side, right?

    Shimel: Yeah.

    Kurtic: You know, should I—when do I trigger auto scaling, when do I not and all this stuff, right? And, you know, we’re now getting much better at that, but you know, if you look at the history just this last decade, it has been a tricky area for enterprise to adopt.

    And so, you know—but I don’t think it’s possible to not. Like, we, just like you said, the speed of business demands that we make automated actions based on data that we are observing, and there are some insights we get from that data.

    The challenge has been, is how good are your insights, right? The tricky part is, I used to be in the SIM space, S-I-M space, so on the security side prior to Sumo Logic. And, you know, it was tricky to be able to sort of adopt full automation based on those security rules, because those security rules themselves were fragile, right?

    Shimel: Yep.

    Kurtic: They weren’t necessarily overly deterministic, you could get false positives, you could block CEO’s e-mail, you know, inadvertently and prevent something important from happening. And so, it was a—in those days, it was much harder to sort of bet on that automation, right?

    As you fast forward to now, when you apply advanced analytics—this is why we call our platform an intelligence platform. When you apply advanced analytics, you know, more sophisticated technologies like machine learning and AI, when you start sort of looking across not at individual incidents and alerts, but you start looking across multiple incidents to really have a better understanding of what’s the actual impact of these events that I’m observing, then you can start, you know, making those automated actions.

    And of course, there’s always gonna be things you will not know how to act on, right, which then goes into a wholly different pipeline that, where you enable people to understand what’s actually happening and then decide, in the future, do I wanna make this an automated action or not. But basically, as we go through this cycle of, you know, capture a new unknown, learn what it is, route it to the right place—when it becomes unknown, it gets added to that sort of automation engine, and eventually, you keep sort of reducing the number of manual steps you need to perform to run a good business, to run a secure business or whatever it might be at the use cases.

    And so, we’re not done, right? There’s still plenty of situations where you’re not gonna wanna take an automated action. But I think at this point, we’ve achieved the level of intelligence to make that automation actually be useful without hurting you.

    Shimel: It does my heart good, man. [Laughter] I gotta be honest. So, I think I mentioned to you off mic that my last startup was a security company I started in 2001, and that’s when we were making the move from, like, IDS to IPS, right? Intrusion detection to prevention, which meant automated blocking of traffic.

    Kurtic: Mm-hmm.

    Shimel: And, you know, I always thought it was a no brainer, but it really wasn’t, because the state of the art at the time was, we didn’t have an intelligence platform.

    Kurtic: Mm-hmm.

    Shimel: Right?

    Kurtic: That’s right.

    Shimel: You know, we were constantly trying and striving, but, you know, it just wasn’t there. So, Bruno, what would you—and, you know, there’s a tough one—what would you point to that has really sort of moved the needle in this evolving intelligence platform that you could say, “Hey, man, you can trust this now, right, because 99 out of 100 is making the right choices, or 999 out of 1,000.”

    What is—you know, you alluded to it, but let’s get down into it. What’s providing, what do you think triggered it? What do you think was the breakthrough?

    Kurtic: Yeah, so, I would say that it’s definitely not one thing, right? It’s multiple things.

    Shimel: Yeah. It never is, right?

    Kurtic: Exactly. So, I’d say it’s sort of, you know, there’s a few sort of things that have occurred in the last decade at least that we have done internally to bridge this gap, right? At first, the old systems were siloed. They were not scalable enough to actually be able to ingest all of the telemetry required to make these decisions, right?

    So, you have to compromise. Like, if you’re sort of familiar, since you’re familiar with IDS and IPS, you might be familiar somewhat with the old SIM systems, right?

    Shimel: Sure.

    Kurtic: The SIM systems of the old age were, you know—you have to compromise. You couldn’t scale them sufficiently to accept all the telemetry, and so, you have to continue to reduce the amount of data that you were sending into them. And when you have limited visibility, it is much harder to be able to make a deterministic decision on what you can act on automatically, right?

    We’ve built a highly scalable, cloud based microservices multi-tenant back end that can basically accept literally almost an unlimited amount of data, right? And so, we get all the data and all the required telemetry to be able to make those decisions, which then creates a different problem, right? Now that you have all the data, how do you actually make sense of it all, right? And, you know, the data analytics techniques have dramatically improved over the last decade. You know, the old world used to be strictly rule based, and if you know this in sort of the IDS and IPS world, like, it’s basically signatures, right? In the SIM world, it was rules, right?

    And now we’ve moved away from that, right? We don’t even require our customers to tell us what the schema of their data is, because in the new world of high speed software development and DevOps, there is no schema, right? Developers put whatever they want into their logs of whatever metrics are coming from that infrastructure. And so, you need to be able to deal with the fact that this data has no schema and you’re gonna have to deal with the schema on demand and still need to be able to derive intelligence from that.

    So, we built a back end that then allows any data to be ingested, any data to be indexed and analyzed. And then, as you analyze that data, we realized very quickly that even if you have a very scalable back end and a very open ended sort of platform that can accept any data, giving a human a keyboard and a coding language is insufficient in empowering that human to actually construct what they actually want to derive out of this, right?

    So, we invested heavily into a couple of things. One is, you know, from the very beginning, we invested into automated techniques for analysis—advanced statistical analysis, machine learning, and things like that, that basically are special purpose built for these types of data systems where, you know, they detect anomalies, they detect outliers. They enable you to sort of remove 99.9% of stuff that is noise and sort of highlight and find all of those things that are real signals in that data.

    And the second part that we talked about last year, which was one of the big innovations we delivered, was something that we called global intelligence service, which basically leverages all this telemetry that we see across sort of the global infrastructure that we run. And it’s able to sort of derive what I would call best in class behavior. What are you expecting to see to happen on this type of infrastructure, right? If I see 1,000 pieces of infrastructure that is common across hundreds of our customers, and I know that this is what’s normal—well, that can tell me whether your stuff is normal as well, right?

    So, there are all these novel heuristics analysis techniques that can inform those decisions as you then run those automations on the back of them.

    Shimel: Yeah. So, you mentioned, Bruno, you were working—was that on ArcSight before, or a different SIM?

    Kurtic: No, actually, my other founding members were at ArcSight. I was at a company called SenSage, which was competing with ArcSight.

    Shimel: Okay. I—yeah, those were my days, those were my peeps.

    Kurtic: Yep.

    Shimel: But, you know, you’re 100% right. You know, they say you can’t make wine before it’s time. And as much money and effort and blood, sweat, and tears that we poured into SIMs back then, they were almost at some level doomed for failure, just because it was state of the art, right? It was—

    Kurtic: Yeah.

    Shimel: You were always trying to dumb down the amount of signal in there and reduce the signal to noise and what you can do and what people would trust with it. And, you know, in many ways, kinda that, that right there, the flip side of that is kind of the success story behind Sumo Logic—right platform at the right time.

    Kurtic: That’s right. That’s—and we’ve learned those lessons, right? All of the founding teams, Sumo has seen how it worked before, right? And when we started the company, we wanted to build something different, take this to the next level, and that has been the task for the last 10 years.

    Shimel: Yeah, 10 years in the making, another overnight success. [Laughter]

    Kurtic: Right, yeah.

    Shimel: Now, we’ve got this platform, we are—you know, we’re in the right place at the right time. Let’s assume we are. Where do we go from here? Where do we go from here?

    Kurtic: So, where do go from here? So, you know, where we go from here, I think, is—we, as a company, sort of, we deliver on this vision of the continuous intelligence category and platform for our customers. Where we are moving into is, we’re moving into sort of fine tuning and shipping multiple products that are optimizing the outcomes for specific user personas and use cases.

    So, I’ll give you some sort of examples of that. You know, on the DevOps side, right, we’ve spent a lot of time on the use cases around cloud, multi-cloud, packaging out of the box solutions for people running in AWS, GCP, in Azure. We recently introduced a, what we call a Kubernetes solution. So, as more and more of our customers move into solutions like—into platforms like Kubernetes and containers and serverless, they’re looking for out of the box insights that, as soon as you plug the data coming out of these platforms into a platform like Sumo Logic, they want to know what—how is my application, how is my platform doing, right?

    So, we’re spending more and more delivering special purpose insights on top of these specific use cases and areas for specific personas. On the security side, we are sort of extending our product set into things like the cloud SIM, you know, tuning it for compliance, again, across specific domains. Like, if you are running on premise or in multi-cloud or in single cloud, we want to deliver more and more specialized packages that basically enable our customers to consume this without having to think too hard about it, right?

    Shimel: Yep.

    Kurtic: The old SIMs were difficult, because you had to write all this stuff yourself, right?

    Shimel: Agreed, agreed.

    Kurtic: Right?

    Shimel: And I think, you know, it’s almost continuous automated intelligence for DevSecOps.

    Kurtic: Mm-hmm.

    Shimel: Right? And I’m not saying that’s the end of the road or the end of history as we know it, right, because we’re in a constant cat and mouse game and as things change, but it really is such a different place than we were 10 years ago, or even five to seven years ago, for that matter, right?

    Kurtic: That’s right, yep.

    Shimel: Bruno, let me ask you personally, right? Ten years in here, you are, you know, the key person developing this, you’ve got this to where it is—what gets you juiced in the morning, man?

    I know I love doing what I do now, right? I got out of the software game, I’m a media person, I love building my company and doing it. What gets you excited in the morning about coming to Sumo and doing this?

    Kurtic: Thanks for the question. It’s actually, you know, if I kind of, when I look at what’s happening, what are the undercurrents here of this market that we’re in, right? We talked about use cases and all this, but the undercurrent here is that there is a massive transformation that’s happening in the technology landscape, right? And the transformation is driven by the business transformation occurring in all industries today, right? Everybody’s—every company is getting remade from inside to go from a traditional business model to a digital business model.

    And these digital business models are then meaning that every single company is becoming, essentially, a software company. And they’re competing not on manufacturing or whatever business they were in, they’re competing on delivering products and services—digital products and services to their customers.

    So, essentially, the entire GDP is gonna be based on software, right? And in order for all of these enterprises and government organizations, you name it, to do this effectively, they’re all going through basically modernizing of how they do their technology, how they build their applications, how they develop them, how they understand them, how they improve them, how they optimize them.

    And we are just at the very, very beginnings of what this market is going to need, right? And I think our goal from the very beginning has been that we kind of want to be that platform for the digital business that’s leveraging all this new stuff, and to enable those users to actually do this effectively. And the challenge that those users have today are sort of, they seem insurmountable today. There’s so much data, right? There’s so much digital exhaust that they have to contend with. The skill sets available to them to actually adopt these technologies are very, very scarce, right? But everybody is going there because there is no other way.

    And so, to me, this is really exciting. We are sort of at this crossroads, this sort of fork and every 18 months today there’s a massive paradigm shift in technology. And, you know, every 18 months, we have to think really hard about how do we now do this and help our customers do that? You know, it’s no longer like two decades ago when it was like, you know, your three tier applications and that trend is going on for 20 years, right? Now, we’ve gone from on-prem, three tier, to cloud, to microservices, to Kubernetes, to containers, to serverless, and God knows what’s gonna happen in six months, right?

    And that’s just really exciting, and having to build—building a company that can respond to that and support our customer base as they go there so they can compete better is extremely exciting for me. And so, that’s what keeps bringing me back and keeps me smiling when I wake up in the morning.

    Shimel: Great answer, man. You know what? It’s a great time to be alive and in this industry, it really is. There’s so much happening.

    Kurtic: It really is.

    Shimel: We’re on the precipice of so much more, though. Because it’s like—you know, the more we accomplish, the more we can accomplish. And that, I think it keeps a lot of us in this, right?

    Anyway, Bruno, I told you we were gonna do this for 15 minutes, and we’re closer to a half hour now, I apologize. [Laughter]

    Kurtic: No problem.

    Shimel: But it was a great conversation, I’m really happy we got caught up on Sumo, you know, and the continuous intelligence platform. You guys are gonna be at RSA, yeah?

    Kurtic: We will.

    Shimel: Yep. So, I’m gonna try my best to have this up for our audience listening to this, RSA is the week of February 24th in San Francisco, and if you’re attending RSA Conference, go check out the Sumo Logic booth.

    Also, we’re gonna be putting on a whole DevSecOps event conference within a conference at RSA on Monday, February 24th at Moscone—I think we’re in Moscone West this year. So, if you have an RSA bench and you want to talk DevSecOps, come join us there. We have a great lineup of speakers. We also can visit the Sumo booth at RSA Conference, which is, I think it starts Monday night the 24th, the expo floor opens and it runs through Friday. So, check that out—shout out to our friends at RSA.

    Bruno, thanks very much, man. Say hello to all of our Sumo Logic people. Keep up the great work.

    Kurtic: Will do. Thank you, Alan. Appreciate it.

    Shimel: Alright. This is Alan Shimel for devopsy.kinsta.cloud. You just listened to another DevOps Chat.

    — Alan Shimel

  • EP 2: DevSecOps and AppSec

    EP 2: DevSecOps and AppSec

    In this second episode of our DevOps Unbound streaming broadcast on TechStrong TV and devopsy.kinsta.cloud’s sister site Digital Anarchist, Mitchell Ashley of ASG and Alan Shimel are joined by Caroline Wong, CSO at Cobalt.io; Andrew Van Der Stock, executive director at OWASP; and Dr. Grigori Melnik, CPO at Tricentis, to discuss DevSecOps and application security.

    The video is immediately below, followed by the transcript of our conversation. Enjoy!

    Transcript

    Alan Shimel: Hey, everyone. This is Alan Shimel, and you’re watching DevOps Unbound. This is episode two of DevOps Unbound, and on our show, which airs biweekly with a monthly roundtable open to the public, we explore topics in DevOps. You know, if it’s DevOps-related, it’s fair game. Today’s topic is DevSecOps, and I realize that DevSecOps has become sort of a mouthful, intrinsically linked into AppSec now and everything we do around that.

    We’re gonna explore today about really, security—whose job is it, anyway? Right? Who, ultimately—there’s a lot more developers, DevOps testers than there are security people, and we increasingly rely on them to make sure our applications are secure, are being developed and released and maintained as securely as possible. And we’ve got a great panel of experts to talk about this today.

    I want to quickly mention, though, this is episode two; episode one aired two weeks ago, and we will be doing our monthly roundtable, so stay tuned on that.

    But let me now introduce you to our panel. Joining me first is Founder and CEO of Accelerated Strategies Group, my partner and friend, Mitch Ashley. Mitchell, welcome.

    Mitchell Ashley: Thank you, Alan. Great to be on with you and with this great panel.

    Shimel: Yep. The rest of the panel, I’m gonna just say their name and who they work or, and if you can give a little bit of your background. Let’s first start with Andrew van der Stock. Andrew, welcome, and if you can introduce yourself.

    Andrew van der Stock: Good day. My name is Andrew van der Stock, I’m the Executive Director of OWSP. I was recently appointed to that role, and I’ve been doing application security since 1998. When we first talked about application security, it was called mobile security, because, well, it was applets and ActiveX controls that were running in browsers. So, it was a rather exciting and very different time.

    Shimel: That took me back—yes, it did. Next, the one and only Caroline Wong. Caroline, you want to introduce yourself?

    Caroline Wong: Hi, Alan. Thank you so much for having me on today. My name is Caroline Wong, I am the Chief Strategy Officer at Cobalt.io. We’re a company that builds security software. I’ve been in infosec now for 15 years, starting out at eBay and Zynga, some of the original DevOps companies, if you will. I also do a podcast called Humans of Infosec, and I’m a LinkedIn learning instructor for the OWASP 10. Almost 10 years ago now, I published a book called Security Metrics: A Beginner’s Guide.

    Shimel: Very cool. And a fantastic speaker, too, I may add. I love watching Caroline present. And then last but not least, a holdover from our first episode of DevOps Unbound, Dr. Grigori Melnik, Chief Product Officer at Tricentis. Grigori, welcome.

    Grigori Melnik: Thank you, Alan. Thanks or having me back and hello, everybody, wherever you are in the world. Yes, as Alan said, I’m the Chief Product Officer of Tricentis, the continuous testing platform and company that’s building the testing tooling for the future. And previously, I’ve been at Splunk, so this is where, actually, a lot of my kind of security mindset has been forged; also, MongoDB and Microsoft. So, good to be here with this panel

    Shimel: Excellent. So, let me start things off and then we’ll be off and running. Andrew, as the Executive Director at OWASP, right, there was a time where, clearly, the OWASP member, the user, the person who was gonna, who you were existing for was the security professional who was in charge of, you know, as you called it, mobile app security and then, of course, appsec has become all the rage probably for the last at least 12 years, right? Appsec is, a lot of people say if it’s not appsec it don’t mean a thing, when it comes to security.

    How has the rise of DevOps, DevSecOps as some call it, some not, how has that kinda changed who you serve, or who does—not you, personally, obviously, but OWASP—who do you guys cater to?

    van der Stock: So, that’s actually really interesting. I had a conversation with Mark Curphey, the Founder of OWASP, a little while ago as I was appointed. And the original thing the OWASP folks worked on was the developer guide, which, it’s a developer guide or developers. And the reality is, is that we missed. We stopped talking to developers. We became very, very internally focused, and we’ve converted the vast majority of the infosec folks to the fact that apps are the firewall. I’ve done almost all my pen tests through firewalls and over SSL. So, the reality is, is that the application has always been the firewall. We should have been talking to developers much earlier than this.

    My personal opinion is that the thing that OWASP has to do right now is to refocus on talking to developers and having tools and information they can actually use in their toolchain. If we’re constantly just having that internal echo chamber conversation, we will fail. And it’s really important to me that we actually start doing more stuff like the OWASP dependency check which can be pipelined, GitHub actions and things like that. These are where we need to start focusing, not on .pdfs, as the person who does the OWASP Top 10 and the developer guide and the ASVS, .pdfs are probably what we’re famous for, but the reality is, developers don’t know of it, they don’t use it.

    I really want us to get involved in Stack Exchange. The number of people who post to Stack Exchange, just to copy and paste stuff, and that information is just wrong? It’d be really great or people like the volunteers and the chapters and the communities to get involved in things like Stack Exchange and other places where developers hang out.

    Shimel: Excellent. I didn’t realize that the original focus was developers. Caroline, you’re in a funny place because you’re Chief Strategy Officer at a security tools company and of course, as you mentioned, you’re a LinkedIn—not professor, LinkedIn teacher or whatever the exact term is around appsec and OWASP. How does that, you know, what Andrew said, how does that jive with what you guys, where you guys see the world.

    Wong: Yeah, so, you know, when I started my infosec career at eBay and Zynga, in both cases, these were companies that were running online operations 24 by 7, with millions of simultaneous users daily. And so, it was always clear to us that we had to get it right when it came to talking with the developer.

    A couple of years before I began my career in infosec in 2003, the first version of the OWASP Top 10 was released. And right now, I wanna say we’re on version 6 or so. Andrew has been spearheading this project for a long time and we’re actually looking at the next revision coming out in February, 2021. If I look at the most recent version, which is 2017 RC2, and I compare that to the original OWASP Top 10 that came out in 2003, one of the things that’s very striking to me is that at least half of the stuff is the same.

    So, that says to me that, on some level, some of these basic security fundamentals that I think appsec practitioners understand are not either being implemented by developers and where is that disconnect? So, I actually think that, as an industry, appsec tends to focus on sort of the hot and sexy things, which is, like, finding cool stuff and really interesting sort of sophisticated breaks.

    But I think that, if you were to look at, for example, the past year or so, you know, if you look at the 10 largest data breaches, I’d be willing to bet you that the majority of those occurred because of something that had to do with, like, a Security 101, basic kind of thing gone wrong. And that tells me that we’ve been really focused on technology, and actually, the hard part is getting the people and the process to work out together.

    So, that’s something that I think a lot about, and I think it really speaks to the core of what we’re addressing today, which is—whose job is it? You know, a security person can find all the vulnerabilities that he or she wants. Until that security person is effective at communicating what the security vulnerability is to a developer who can actually fix it and convincing that individual that it’s a priority enough to actually spend time remediating, then the code will never be more secure.

    So, it’s always needed to be a partnership, and I think that, you know, these days, because of things like the transition of software development methodologies from waterfall to agile to DevOps, I think that culturally, we’re beginning to see some changes.

    van der Stock: I just want to highlight one of those choices that you said.

    Shimel: Oh, I’m sorry—go ahead, Andrew.

    van der Stock: Realistically, the thing that I see as the OWASP Top 10 leader is, it’s self-referential. The things that people pay attention to is the things in the OWASP Top 10. And, in fact, CWE is, the MITRE Group are about to release the CWE Top 25 in a few weeks’ time, and it’ll look like the last one in 2011. And this is really sad, because people are actually concentrating on these.

    What we really need is for developers and security people to work hand in hand, and I would like to see the security folks stop delivering .pdfs and start delivering, you know, pull requests. If you can fix the problem, you don’t have to convince anyone. If you actually start talking in developers’ terms and actually convince the product managers that this is the right thing to do, we’re gonna be a lot more successful than just saying, “Look, your baby is very ugly.”

    Ashley: Andrew, bless your heart—bless your heart. [Laughter] That’s something I’ve advocated for. It’s not that, necessarily, security people have to become the expert software developers, but I think we’ve sort of done this to ourselves by thinking security as a penetration activity, right, something that we’re testing from the outside. I mean, now we’re talking about very porous software architectures and API security and Kubernetes container security. It’s a much more different world than even 5 or 10 years ago.

    So, what I’ve advocated for—and it’s a little bit scary at times, but advocated for security people to learn software architecture, whether they learn how to code or not. But they need to understand what’s going on inside the m&m as well as the outer hard shell, if you will. And, you know, one way to do that is to bring software people into security groups. You don’t have to go learn it all yourself, you can learn from other people and bring in skills, as well.

    But to your point, you know, it’s not an after the fact thing, it’s gotta be right there in the flow and the process. If it gets fixed as soon as you find it because it’s a priority—great. If it’s a day to a week, month later—forget about it, it goes into the prioritization process and it may be months or quarters before it gets fixed.

    Shimel: Grigori, we’re all looking at you, man.

    Ashley: [Laughter]

    Melnik: Yeah, I was ready to jump in to talk to Caroline.

    Shimel: Go ahead.

    Melnik: Because what she said absolutely resonated with me, and then what my other esteemed colleagues just added to it, you know, rings the bell. Because, you know, I always looked at the security—and again, for a very, very long time, I was focusing predominantly on the developer audience, ________ engineer and then the development teams, platforms, tools, and all of that. And, you know, kind of designing for security something that’s been a focus of the teams that I was part of. Starting from, you know, as early as back at the beginning of the century with the Microsoft, if you remember the early days, having the disastrous year 2000, 2001 with lots of worms and breaches and —

    Ashley: [Cross talk] virus —

    Melnik: And then, you know, the bagman CTO, Craig Mundie had the internal initiative that later turned into the actual company-wide letter from Bill Gates, Bill G. himself. And that was the beginning of what’s known as the Trustworthy Computing initiative, which was company-wide. Again, we’re talking about tens and tens of thousands of people had been trained regularly, not just once, but on a regular basis on the fundamentals of security, on design with security. The whole life cycle, we even didn’t talk about SDLC, software development life cycle, we’re talking about secure software development life cycle and all the practices that came from it.

    And it actually beared the fruit, right? Because in general, you look at the history and how much more secure, you know, Windows and Microsoft has become—that’s actually, you know, the results of those early initiatives, right? So, by the same token, I think that when we’re talking about security and whose job is it anyway, we need to start from the ground up. And maybe even before the junior developer, maybe even at school, right, if you think about software engineering schools, boot camps, whatever format you are learning your code in, it’s super important to be introduced to those secure practices, to be aware of the patterns and anti-patterns, right?

    Like, I think ________ and ACM, the official ones that define the curriculum, they had included, for years, the topic of software security in there, but realistically, how many graduates of computer science degree has actually dived somewhat deeply in it, right? It’s amazing that now it’s been so many, what, two, three decades that we talk about, you know, design for security notions and trustworthy computer initiatives, and we still see what Caroline said, the Top 10 breaches—you still see something as basic as a SQL injection attack, right? Cross-site scripting—all that stuff that is almost, you know, I view it as part of developer hygiene, right? It’s just something that you do fundamentally.

    It’s like, these days, it’s not something that developers, we don’t even have this conversation, should developers write their own tests or not? Well, by the same token, there should be no conversation, should developers think about threat modeling, should developers think about, you know, various mitigation strategies? Should they get involved more with the security specialists when it comes to defining or going through the release gate. And yet—and yet, when you look around, those secure practices still hasn’t made into, you know, the mainstream as much as I would’ve liked it to happen.

    So, I don’t know what you guys think if there are some other ways to—it just feels like people start looking at it only when the breach occurs and the you’re facing a massive litigation, right? It’s like—but it’s too late, right? We need to think about all this ahead of time. And, of course, everything that OWASP is doing and other organizations and kind of advocating for security, promoting the secure mindset, this whole movement of DevSecOps, I absolutely welcome it. Because anything that we can do to make developers and everybody on the team to think about security early on as opposed to the afterthought is a good thing.

    Ashley: I have a question or the panel. You know, these vulnerabilities have been around, as you mentioned, Cynthia and Andrew—

    Shimel: Caroline, excuse me.

    Ashley: – Caroline, sorry—forever. And you know, it’s not like we don’t know what they are. You know, we have really smart ID environments that will bring up the objects and what all the methods and parameters are. Isn’t there something we can do, either through AI or just in the tool side so when we’re creating software we have fewer of those basic vulnerabilities, is that—

    Shimel: Spoken like a real security person! I think that sounds too magic bullet to me, but Andrew, go ahead.

    van der Stock: I want to give Caroline some time to answer this, because there’s actually some things I wanna talk about education underneath from Grigori’s talk before. But fundamentally, we need to take the OWASP Top 10 to frameworks and say, “These are the things you must not have—end of story, done. You must not have these.” And then the developers don’t have to think about those other things, and then they can use the developer tools like OWASP Cornucopia, which is like the elevation in privilege game that Microsoft came up with.

    Do you know what? The reason why we do this again and again and again is, we allow people to use insecure frameworks and they’re not given the guidance they need. If we had engineering students who didn’t know about, you know, wind loads and things like that, we’d never have a bridge that stood up. Yet, we allow our computer science and software engineering students to graduate without taking one single semester of security.

    Shimel: Amen.

    van der Stock: That’s why we established an education committee before, and we have to get people to actually do it. The ACM syllabus is okay, but it is focused on crypto, and we don’t need a lot of crypto folks, we need a lot of people who know how to engineer security properly. Now, I want to hand it over to Caroline.

    Wong: Thank you, Andrew. And, you know, Mitch, I love your question, because I think that one of the things that security leaders must think a lot about is what combination of machines and humans to bring into their application security programs.

    So, anyone who’s only using people is clearly missing out on efficiencies that can be found on machines or implemented, as Andrew was saying, with patterns and pre-written things that people should just be using, HSDS. And anyone that’s only using machines is, on the other side of the coin, missing out on entire classes of vulnerabilities, you know?

    So, I think that, ideally, you know, security professionals are working with development teams to use scanners in order to find low hanging fruit and then using that information to provide context for analyzing the risk that’s posed by those issues. I think it’s absolutely a hand in hand sort of thing, even if one of those hands is a computer hand. And, you know, kinda the more that we can do via automation and by simply using secure libraries, using secure frameworks, you know, that allows the sort of precious and often more expensive human technical skills to be focused on things that can’t be found by machines. Finding things like business logic bypasses, race conditions, chained exploits—those are the kinds of things that people should really be focused on. You know, not things that can be solved by, again, simply, in quotes, because to get folks to actually do it turns out to be a whole, another challenge in and of itself, but I really do think it’s very much the mix of both.

    Shimel: Agreed.

    Ashley: I love the framework idea, too, Andrew, and thank you, Caroline—sorry to mispronounce your name earlier. [Laughter]

    Wong: Just think of “Sweet Caroline” like Neil Diamond and you’ll never forget it.

    Ashley: There you go. What a wonderful way to remember your name. [Laughter] You know, I wonder, too, if you layer on top of putting into the framework, security people love sort of standards like a NIST framework or something like that. If there was something that, “Okay, all of our frameworks must meet this,” right, then that’s gonna get kinda into the process and the psyche of the organization to say, “Okay, we’re only using software that meets blah, whatever that is,” it seems like that’s one more element that would help with the adoption of standardization of that. Is that practical for something like that to happen.

    van der Stock: So, I’ve really been pushing for the idea of the generally accepted security principles, the equivalent to GAAP in the accounting world. There are some fundamentals that we should be trying to do.

    The very, very, very, very first NIST special publication had the OWASP Top 10 in it. It was written in 1976.

    Ashley: Wow.

    van der Stock: It was classified.

    Shimel: Really …

    van der Stock: When it was—yeah. When it was unclassified and I found it, I found it as I was preparing the OWASP Top 10 2017. The only thing that we don’t have in the OWASP Top 10 is race conditions. Those guys had race conditions in the first one in 1976 when there was just mainframes and they only had one processor and they did things in batch. And quite frankly, for them to think that far forward just shows how early those folks were thinking. However, I think we need to make sure that we give the developers time to think about the desire for security.

    I just want to touch back on what Grigori said before, and I think this is where strategy comes into it. When Microsoft, when Bill Gates wrote that memo, they then followed it up with action—executive action. They reset the Longhorn build. Windows 2003 server release 2 is a very different beast in terms under the head than the original 2003. And what was released as Vista was very, very different to what XP was, and that then created Windows 7.

    So, quite frankly, it was—yes, we need support from the top, and we need people at the bottom to understand what this really means. But the fact that they had executive support means that things like SQL server just doesn’t have remotely exploitable bugs today. You know, that is a really good outcome, and it’s because of executive support.

    Shimel: Agreed, agreed. So, you know, we live in a world right now where, quite frankly, without modern applications that we’ve been surviving on these past months with COVID and everything, imagine how ugly it would be without them. But do we really—do we really have that executive support, maybe not to the level of Bill G. and Microsoft and the Trustworthy initiative. But Caroline, at Cobalt, you’re dealing with dozens of organizations, right? Andrew, you know, at OWASP, hundreds of organizations. Grigori, Tricentis has how many customers that you guys are providing—hundreds as well.

    Do you really see that top-down support at most organizations, or was that Microsoft thing sort of a catching a firefly in a jar kind of thing, lightning in a bottle, right? You’re not—we just don’t see that, unfortunately.

    Wong: So, I’ll tell you what. A lot of times, when I think about security, I kind of go back to, like, the principal concept that the only reason security matters is when you have value to protect. And so, these days, naturally, a lot of value is moving from the physical to digital worlds—cyber security is more important.

    I’d actually really like to challenge something that Mitch and Andrew put out with regards to sort of an all-encompassing security framework that says everyone’s gotta do this. Having worked on the ISO 27034 standard, I’ll actually ask if anyone on this panel has even heard of the ISO 27034 standard. Cool, so that’s great, Alan. [Laughter]

    van der Stock: So, I actually tried to provide advice to that when it was coming out, and I couldn’t because I was part of the national organization and that’s the reason it failed.

    Wong: You know, there are a lot of different things, right, and I think that the standards route is one that we’ve been trying. And I think that sometimes it works better than others. What’s really gonna work is the market route.

    So, when Bill Gates wrote that memo, my understanding is that Bill did not do it for any sort of noble pursuit. He did it because he recognized that if Microsoft was going to continue building security vulnerabilities into their products, that they were gonna lose customers, that they were gonna lose market share.

    And so, what’s kind of cool that I see happening when I talk to our customers like VeriFone and MuleSoft and health care organizations and HelpSpot and financial organizations is that, due to the proliferation of cloud and SaaS, today it’s not like you have a CIO who goes and plays golf and has steak dinners with their one big IT software vendor. You know, now, anyone in an organization with a credit card and an Internet connection—buy something and it becomes shadow IT.

    So, the whole concept between these business relationships of trust has been transformed. And what you see is tons of software companies using tons of other software companies. So, every software company is also a buyer of other software products and services, and that business transaction requires a level of trust, where I’m seeing customers asking for things like a penetration test in order to prove that there’s some adequate level of security before a business engagement begins.

    So, my perspective is actually that frameworks are cool and great, education is cool and great. And I think it’s really gotta be the market that drives the power and the adoption and the prioritization of security.

    Ashley: You know, Caroline, there was also—thinking back to the Microsoft example Andrew was talking about—I think an important factor in that was Apple, because they were marketing very heavily as a secure —

    Shimel: That was it, yeah. Microsoft was afraid of Apple.

    Ashley: So, they have competition, you know? And I hate to use the Vista word, but you know, there was some pretty crappy software that had a lot of security vulnerabilities in Microsoft’s code, and that’s—it was the market, as you said, but it was also competition. Because that’s when Apple was doing pretty well or at least rising up in the laptop market.

    Maybe there’s some group of vendors, companies that band together and say, “We’ve got better software because it’s more secure” and that now becomes more attractive. I don’t know, something like that might happen, too.

    van der Stock: So, we just got involved with the—sorry, just really quickly. We just got involved with the Linux Foundation and we just established the Open Source Security Foundation, the Open SSF. And it’s early days yet, but I see that as actually being way more successful than, for example, ISO 27000. Not 27034, which has got very low adoption, but 27000 bakes in a risk-based approach which says the business needs to only do that that it thinks is right and can’t really hurt it. And unfortunately, that then becomes whack-a-mole, whereas the Open SSF works from the other way around that I think, you know, with the participating members of GitHub, Google, IBM, Red Hat, and others, and obviously OWASP, we’re gonna be able to do a lot more there than I think in a traditional standard-setting body.

    Shimel: I wasn’t aware of that organization, Andrew. That sounds fantastic. We’re gonna look into it here and see what we can do to help get behind that—really, really good stuff.

    Grigori, I know you wanted to talk and I’m gonna give you a chance before I jump in.

    Melnik: Oh, no, I was just gonna kind of sum up—so, we talked about the importance of frameworks, we talked about the importance of market forces driving these secure initiatives, now the new organizations that have been put in place. But I am still convinced that it’s the developer’s mindset that needs to do sort of the most in order for us to be, you know, winning in this space.

    So, doing whatever it takes to take them, take us, the developers, the responsibility for security. It seems like somebody else’s job—“Oh, I have this broadsec group that, you know, that looks at the metrics and the static scans and then occasionally does some kind of a penetration test and exercises or whatever and then sends me a bunch of reports, many of which I’ll try to justify as by design.” No. It’s like, as I’m doing my job, day in and day out, to be thinking about the security, to be thinking about, “Okay, what are the different ways how it can be breached?” and again, making it part of my daily routine, I think, is important.

    I can tell you, internally, at Tricentis, I kind of, I’ve been in the process of launching this Trustworthy Computer Initiative, because we have opportunity to improve in this space, big time. But I can tell you, even with some easy things where, you know, we do things like hackathons, right? Not everybody participates in the hackathon, right? So, what we did at MongoDB, I actually loved it, and that actually did require a little bit of effort, but we had our Product Security person put together this type of competition, kind of catch the flag where you would actually have this increasing set of security challenges where you would have to go and break in or identify all these different holes and then, of course, reflect on that.

    And actually, that raised awareness of many, many, many, many developers. So, I’m just thinking about what can we do with, you know, the small wins, small initiatives, not necessarily at the level of defining the major standards and pulling the big initiatives, but in this kind of a baby steps to move the needle, I think, is important. The other point —

    Shimel: I got—oh, I’m sorry, go ahead, Grigori. I was just trying to get to my next place in line, but you go.

    Melnik: Ah, okay. No, the other point I was going to make is that I also think that, for the future of the Internet becoming safer and securer and all of our systems, the other dynamics or the other initiative that I’ve seen happening and getting more and more popular, this whole collaborative testing or collaborative secure, you know, that companies like Hacker One is doing by engaging the white hat hackers in kind of—

    Shimel: [Cross talk] and stuff.

    Melnik: – inviting them. In fact, inviting them to go and launch the attack, but for the purpose of learning and raising awareness. And even, you know, if you look at the Department of Defense and Pentagon, inviting hackers to hack into the Pentagon systems, I mean, if you think about it, 20 years ago, that wasn’t heard of, right? But what they’re doing there is that, actually, they’re making sure that you get all these diverse perspectives, that you’re not only looking through the narrow angle of your Security Department, but this broader community at large participating; i.e., I think that there’s some hope at the end of that tunnel with the right level of engagement with those collaborative testers, white hat testers that the overall security posture of the Internet, of the world will be improved.

    Shimel: I think bug bounties have certainly been a game changer. I don’t think anyone disputes that. But I’m gonna tell you something I’ve learned in my 20 plus years in security. And that is, security, as much as we may want to think of it as not a different animal than many other disciplines within IT and in business in general, and market forces—market forces rule, right? So, security becomes important when the business decides security is important, right?

    I remember, you know, having a conversation—I did a podcast with the CEO of MongoDB and Couchbase and Rich Mogull, who I think most of us on the panel probably know Rich. And this is 10, 12 years ago on Network World, I was writing, and I asked those two CEOs, I said, “Does NoSQL stand for no security? Right, because we don’t see a lot of security in the”—this was a long time ago. And they both said they agreed, they said, “Alan, we will build security in, more security into our products when our customers demand it. Right now, customers are more enthralled with having this new type of non-relational database, NoSQL, you know, database that allows us to be more flexible, faster, scalable and all that, we’ll get to security, right?

    A couple months later, MongoDB had a pretty decent breach. Microsoft is a great point. Apple was starting to kick their butt, and the word on the street was, even though Microsoft gave you free AV, maybe, you didn’t need AV on Apple. Remember those commercials? “I don’t need AV, I run a Mac.

    And so, it’s over and over. When we make security important, you know, Grigori, you guys are the leading continuous testing provider in the world. When your customer starts saying, “Grigori, we’ve got to test for security as well, because that’s part of our quality, right, that’s the Q in QA and we need Tricentis to give us those tests and you go to companies like a Cobalt or you go to the organizations that Andrew’s talking about and stop building that in there, because your customers demand it. Not because it’s the right thing to do, not because it’s a nice thing to do, because it’s demanded, then you’ll see how quick developers take security seriously.” It’s the market.

    Melnik: And it is happening. Alan, it is happening. The customers are, absolutely, they are, you know, demanding this. They want to see the evidence and they want to see, they want to have the tools and, again, everything from security testing and static analysis, but a lot smarter, you know, augmented with ML to dynamic analysis and actor-based models and, you know, penetrations and all the way to compliance, right, and a lot of other things.

    And you’re absolutely right. I mean, with, back to the days of MongoDB when the initial releases were not very secure, because the idea—they were optimizing for the wrong thing. And this is what I fear was ________. They’re optimizing for adoption. It’s like—get me as many users as possible. How do you get as many users as possible? You lower the entry barrier. Now, if you lower the entry barrier, then automatically, that means that you’re sacrificing some security, right? Just like, again, allowing and opening up the ports and local hosts with MongoDB and all of it in the old days, that’s what had happened. Now, all of that has been tightened. You know, you had the security of trust, you have the security in transit, they’re doing all kinds of phenomenal stuff with encryption, fill level encryption, all of it, but it took like a decade to get to it, right?

    When you are at the beginning, you’re putting something in there and you’re trying to win in that race to get more of the magic number of MAUs, right, the monthly active users, a lot of companies and a lot of startups, unfortunately, tend to sacrifice security for that speed to market and user acquisition, and then bites them later, right? So, again, if there is some way to raise the awareness and to think about it early on so that you don’t end up with the unpleasant situations later on, I think that’s something that could change the world.

    Shimel: Agreed. Panel, we are, we’re getting near the end of our time, and we have such shy wallflowers here, no one wants to talk. [Laughter] So, I know how long it’s gonna take us to wrap up. I’m gonna give you each a closing, if you will. We’re practicing for the debates, here. We’re gonna give you each a chance to leave the audience with the most important thing you want them to leave. And Andrew, also—is it called the Open Source Security Foundation, OSSF?

    van der Stock: Open SSF, yeah.

    Shimel: Open SSF?

    van der Stock: So, the Linux Foundation—yeah, the Linux Foundation announced it.

    Shimel: Is there a website yet for that?

    van der Stock: Go to the Linux Foundation first, and then you’ll find it. It’s one of their initiatives. I don’t know that there’s a special site for it.

    Shimel: Alright, love to hear more about that. But Mitchell, do you wanna start off and we’ll—your screen’s different than mine, but on my screen, it goes Mitchell, Grigori, Andrew, and we’ll let Caroline bring it home.

    Ashley: Okay, great. I’ll make mine brief. I’m actually very optimistic, and I mean this with all sincerity, that listening—people like Caroline and Grigori and Andrew, they’re some pretty brilliant people that are thinking about this, and all of you had a different but also shared some perspectives. So, I’m hopeful that we’re gonna make some progress here in the near future, so thank you for working on this problem. That’s what I have to offer.

    Shimel: Thanks, Mitchell. Grigori?

    Melnik: So, I wish I actually wore a different shirt today. I had a T-shirt from Splunk and, you know, they have some clever slogans there, but one of them said, “Ignorance is not a bliss,” and that’s my message to all of the developer community. You know, ignorance is not a bliss. Learn security, get the security mindset embedded, you know, from the get-go, from as early days as possible. The engineering managers think about it accordingly and embed security into your teams early on.

    And then what Andrew said earlier, I absolutely sign up for it, and I love that this whole notion on the side of the security specialists, security experts—when you’re coming in, don’t send me .pdf reports of, you know, 275 pages and 722 vulnerabilities. Pull requests for the win. Pull request wins today. Pull requests, you know, really, really work. Everything else is just talk. So, again, if security specialists can get more into that written and be more embedded and more attuned to what the developers want and need, I think, jointly, again, we will definitely make a difference, so—thanks.

    Shimel: Thank you, Grigori. Andrew?

    van der Stock: So, many, many years ago, we wrote the OWASP Developer Guide and then I think the OWASP Top 10, and I realized telling people what not to do was exactly the wrong approach. We need to tell people how to do what they want to do better to enable secure business.

    So, the application security verification standard, which I work on, is a set of tests. It’s literally written for developers. It’s literally written to be testable. And this is actually, I think, really important. We need to change the mindset from a negative, “you shouldn’t do that” to a positive, “how about doing it this way?” Because sometimes the developers have a better idea altogether and we just don’t know. But many security folks have the mindset, “I know better than you.” But they’re not software developers, they don’t know.

    We need to have a conversation together, and I want to make sure that we’re bringing in developers into the conversation and not treating them as, you know, people who don’t know that much. We don’t know that much, either, and I would like for people to have that bidirectional conversation in a positive, not negative fashion.

    Shimel: Fantastic. Caroline—it’s all yours.

    Wong: Alright, so, the thing that I’d like to leave folks with today is, I’d invite folks to check out the 2020 State of Pen Testing Report, which I wrote and co-authored with my colleague, Vanessa Sauter. One of the topics that we dive into pretty deep in this report is sort of the relative capability of machines and humans to find different kinds of web app security vulnerabilities. In addition to drawing upon more than 2,500 penetration tests, the data of which exists in the Cobalt platform—and Andrew, I did connect with your colleague, Eric, so we’re gonna be donating some data to the next OWASP Top 10 project.

    But in addition to that, we also surveyed more than 100 practitioners in security development, operations, and product across a wide range of industries. And the really good news that I’d like to leave folks with today is that the majority of respondents, in fact, 78%, reported a strong relationship between the security and engineering teams, and we do expect that to grow in the future.

    Shimel: I sincerely hope so. Guys, you know, someone much smarter than me once told me that when you want to impress people and you get in a meeting, you know you got a real great group when everyone there is smarter than you. [Laughter] So, thank you, all. I really felt like we had an amazing—what amazing brain power on this one.

    I want to thank you, all, for joining and contributing. We will try to put in the notes on this one some of the links to a lot of the sites that were mentioned, reports that were mentioned, et cetera. We’d love to have you back on, you know, maybe at some point in the next month or two, we’ll do a roundtable on this topic, we’ll add another person or two. Caroline, I know I had spoken to Chenxi, actually, Chenxi Wang about coming on, so I would—because I like listening to Chenxi talk about security. But anyway, and we’ll open it up to—yep, we’ll open it up to the public for questions and it’ll be a great time.

    But for now, guys, thank you so much. Andrew, best of luck with the new ED position there, and I know they picked the right man for this job, so make us proud, keep making us proud. Dr. Grigori, we’ll see you soon, hopefully on another DevOps Unbound. Okay, and Mitchell, as always—thanks so much. We’ll be in touch.

    This is Alan Shimel. Many thanks to Tricentis for actually sponsoring DevOps Unbound, couldn’t do it without their sponsorship and help, and we’ll see you in two weeks with another episode of DevOps Unbound. Have a great day, everyone.

  • DevOps Chats: Kubernetes is the New Compute, with Rancher Labs’ Sheng Liang

    DevOps Chats: Kubernetes is the New Compute, with Rancher Labs’ Sheng Liang

    Rancher Labs is a great example of a startup that was smart enough to sense the way the market was moving and adopted a strategy to capitalize on it. And, if you know Rancher co-founder, CEO Sheng Liang, you should not be surprised. Sheng has been seeing the market and staying one step ahead for a long time.

    In this DevOps Chat, we sat down with Sheng and spoke about the recent momentum at Rancher. We also spoke a lot about Kubernetes becoming the industry standard for compute.

    It is always a good learning experience speaking with Sheng, and this conversation is no different. Have a listen.

    Transcript

    Alan Shimel: Hi everyone, this is Alan Shimel for devopsy.kinsta.cloud and you’re listening to another DevOps Chat. I’m really happy to be joined by a good friend of mine who I’ve known probably more years than we want to admit to, my friend Sheng Liang who is the CEO of Rancher Labs. Sheng, welcome.

    Sheng Liang: Thank you very much. I’m glad to be here.

    Shimel: I’m glad to have you here, my friend. So, Sheng, the news with Rancher, I guess we call it a momentum release, right, you recently put out.

    Liang: Yeah.

    Shimel: Why don’t you just share some of the highlights with the audience?

    Liang: Yeah. Every January, early February, we tend to look back the year before and see how we’ve done, how the whole industry has done, and it’s just been remarkable. I guess the top-level thing is our business, our recurring revenue grew 169%, so that’s like high three-digit growth. It’s way exceeded our expectation. That itself is good news for us, but it’s not really–I don’t think an average person in the industry needs to care about it as much.

    What I want to, Alan, spend some more time talking to you is some of the underlying technology changes and industry movement that’s kind of enabling us to thrive in this environment.

    Shimel: Absolutely. Let’s be fair, congratulations. A hundred and sixty nine percent year-over-year growth is nothing to sneeze at. You’re right, there is a little bit I think of a rising tide lifts all boats when we’re talking about the Kubernetes market. Nevertheless, 169% is still 169%. You and I both come from that startup world and congratulations.

    Liang: Thank you.

    Shimel: It’s something to be proud of.

    Liang: Yeah.

    Shimel: Also, for our audience out there who are not familiar with Rancher Labs and Rancher OS, it’s a great startup story. Sheng, your background, cloud.com, all the things you’ve been involved in, you’re the perfect person to have led this. But Rancher Labs came out there originally with the Container Revolution, right?

    Liang: Yes.

    Shimel: With an OS for running containers. You were agile, nimble, adaptable enough to see Kubernetes and say, “Hey, we’re not gonna–we’re shoveling sand against the tide, right, if we think we’re gonna beat Kubernetes. If you can’t beat them, join them.” You incorporated Kubernetes into the Rancher Lab system.

    Liang: Yes, and in a fairly unique way as well. I’d love to share the story a little bit if you don’t mind.

    Shimel: No, you’ll tell it better than I will.

    Liang: We’re just over five years old, over 200 people now. We operate in 14 countries and we’re open source business. It’s 100% open source. Every single product we ship is available free in source code form, Apache open source, and it really worked well for us. I know in the industry there’s actually been a lot of talks about “Is open source even a great business anymore in the context of cloud?” But we continue to believe so, at least especially in the industry we’re in, and we can talk a little bit more about that.

    But let’s talk about the business and market and Kubernetes. The great opportunity we see with Kubernetes is Kubernetes for once has become an industry standard for compute. Now, think about it. We all know compute these days is everywhere. Computing is on cars, in ATM machines, on your phone, certainly on the server, in the cloud, but really, before Kubernetes where the world was getting into was quite challenging for a lot of organizations.

    Because these clouds as good as they were, as good as they still are, they’re just different. If I’m a CIO, say if I wanna be efficient, I wanna maybe go all in on one cloud whether it’s Azure or Amazon or Google, but until the day comes, now I merge with another company and now bringing a whole different set of infrastructures, and I don’t really wanna worry about that because my whole point is develop the apps, transform the business, help the–all the stuff I’m doing to worry about infrastructure is just plumbing, and that’s the true power of Kubernetes.

    I don’t think enough people in our industry are promoting Kubernetes this way yet, so I’d like to make a strong point with you, that in my mind, Kubernetes is the TCPIP of compute. Now, think about it.

    Shimel: It’s the stack. It’s the [Crosstalk] as you say. It’s the protocol.

    Liang: It’s a stack and a protocol because before TCPIP if you and I could remember back in–

    Shimel: I do remember.

    Liang: There were a handful, almost a dozen different network protocols, and after TCPIP we had 3Com, we have Cisco, we have Yahoo!, we have Google. All that stuff happened, internet. Revolution happened because finally–

    Shimel: I remember when you had to add the TCPIP stack separately. It didn’t come with Windows, so you had to add that in. That was an add-on. Early open source stuff.

    Liang: That’s exactly what’s happening because–this is a great point you brought up. Someday people will say, “Oh, I remember there was a time I had to talk to vendors like Red Hat and Rancher just to implement Kubernetes, whereas today if I get infrastructure like from Amazon, Google, from VMWare, from Dell, wherever, it comes with Kubernetes.” That’s exactly the same thing that’s happening. You see that, right?

    Shimel: Yeah. History repeats itself. When you get old enough, Sheng, you realize that. Let’s talk something else. I wanted to talk a little bit about CNCF because that’s their mission to make sure that Kubernetes is part of the plumbing. Truthfully, it’s not just Kubernetes. When you look at CNCF’s mission, they truly are trying to develop a stack or at least help foster the development of a stack built on several open source projects.

    Beyond Kubernetes, for Rancher now, what are some of the other CNCF projects that you see making their way into Rancher either now or in the future?

    Liang: I would say pretty much the whole stack. We’re very deeply involved in CNCF. We’re very early member of CNCF, and my co-founder Shannon Williams is elected to the CNCF governing board. Just this week I was elected to the CNCF TLC.

    Shimel: Really? Congratulations.

    Liang: So, I have some power kind of deciding what projects are gonna go into CNCF. CNCF fundamentally is a governing body for projects, and really our goal is anything and everything that–we wanna provide basically the complete software stack that organizations need to complete their cloud native transformation. Kubernetes is really just the start. Beyond Kubernetes you see everything else that’s going on from monitoring to logging. I’m talking about projects like Prometheus and ____.

    Those are some very mature projects now. Some of the more recent projects, things around security and policy management like OPA. I think those are very, very–

    Shimel: Love OPA.

    Liang: Yeah, and service match Linkerd. That’s also part of our CNCF. We last year contributed to a project called Longhorn. It’s cloud native storage, Kubernetes storage into CNCF. It’s a CNCF sandbox project now. So, it’s pretty much really the whole stack. If you think I was saying Kubernetes is TCPIP, then the rest of the CNFC, it’s the rest of the software stack, from the platforms to some of the key applications to some of the tools and equipment that more people have used.

    They’re gonna build this cloud native ecosystem. So, I’m really excited about it. I’ll be serving this CNCF technical oversight committee for the next two years and play a role in really growing the scope, further grow the scope of CNCF.

    Shimel: I just wanna say one other thing about CNCF, and that is we did a virtual event here called Predict last month where we took a look at a year in the future, and one of the points I made is that to me, CNCF is sort of the poster child for this third generation of open source that we’re in. I call it the first stage, sort of the cathedral in the bazaar back in the day. I know you know about it, Sheng.

    And then we moved from the cathedral and the bazaar to what I call the big brother era where every open source project was really owned by one company, and everything that that project did was for the benefit of one company, and that discouraged others from joining in and helping do it. Now we’re in sort of the foundational era of open source where you have foundations managing these projects for the good of the whole community with multiple vendors involved, people like you on the board who are doing it.

    Yes, it’s good for Rancher, but it’s good for all of the community, and that’s a very different–as I said, it’s the third generation of open source and it’s a great thing. Let’s focus in on Rancher a little bit though, Sheng.

    Liang: Yeah, absolutely.

    Shimel: So, we’ve got all these great projects. You’re literally building the stack or at least distributing the stack, your distribution of the stack. Fantastic revenue growth. What are people doing with Rancher that this demand is in such high demand?

    Liang: Yeah, I know. It’s one thing that Rancher of course supports and distributes a lot of CNCF technologies including Kubernetes and Prometheus and Linkerd and Fluentd, and we’re gonna soon be doing OPA. That’s all valuable, but fundamentally, a company like us really only have a reason to exist if we innovate. We basically create things that people can uniquely get from us and not from anywhere else.

    There are two pieces of content or two technologies that we created that actually help put Rancher on the map. One is K3S. It’s one of the most–if not the most–popular open source project in the Kubernetes ecosystem today outside of Kubernetes itself, and it’s just got tons of momentum. What K3S achieved was it took Kubernetes that was already proven in data center and cloud, and we brought it out to Raspberry Pi’s and surveillance cameras and set top boxes.

    Shimel: This is K8 lite. I remember we spoke about this, the one in the KubeCons. I remember.

    Liang: We launched GA at KubeCon, so it’s very big. We’re very excited about it. You remember, again I keep using TCPIP as an example because in the 90s when TCPIP just came, it was obviously a computer networking standard, but nobody probably could’ve imagined like a phone would also be talking TCPIP, right?

    Shimel: They all do.

    Liang: They all do now. I can see in ten years every phone, every camera will be running Kubernetes as well. Every car will be running maybe multiple Kubernetes. So, we’re very excited about that. Then the other big piece of innovation that really Rancher helped to make it happen is this thing called multi-cluster management. We believed Kubernetes again is a protocol. It runs everywhere, so you kinda need something to tie them all together.

    It’s not really good enough to be able to operate individual clusters. You need to treat all the clusters as a resource pool. In fact, you actually kinda have to treat every single cluster as a cattle or as a pet. That’s where the Rancher analogy came in.

    Shimel: I remember talking to you about that three, four years ago.

    Liang: I know.

    Shimel: It’s cattle, not pets.

    Liang: Our namesake product Rancher, which is named after our company, is a Kubernetes management platform. It takes all of your Kubernetes clusters in the cloud. In the cloud, that could be GKE, EKS, AKS. Could be Kubernetes clusters on-premise. It could be RKE. It could be open shift. It could be Project Pacific, PKS. It could be K3S clusters on the edge in cameras.

    We present it to your DevOps teams and ITOps teams as a unified computing platform, so you can manage access, you can deploy apps, you can run CICB, and that’s what Rancher is. It really started to resonate last year, even though we’ve been building it for three, four years, and that’s ultimately what propelled our tremendous business growth last year.

    Shimel: Great. Sheng, we’re coming up on the end of our time. I’m gonna throw one more kind of topic question out at you we can discuss, and that is really what does the future hold for Rancher not necessarily from a product deployment point of view but you’ve started and had exits with multiple startups now in your career. Where do you see Rancher in two to three to five years? Do you go public with this? Is this something maybe some larger entity wants to acquire to kinda own the stack if you will? What do you think?

    Liang: I think these days I probably think a little less about ultimately how Rancher will exit, just making sure we build a great business. I think we’ve kind of grown past the point that sort of an early stage easy equal hire or a technology would be viable.

    Shimel: It’s not a tuck in.

    Liang: We’re big enough to be sustainable by ourselves, and honestly, I absolutely believe it’s a big enough market. We solve a big enough problem that there’s a potential for tremendous business. Think about people actually all talk about hybrid cloud and multi-cloud, edge computing, but I think a lot of these terminologies are very attractive from a market demand or business case perspective but always lack some technical meat to actually bring it to reality. That’s actually been the problem.

    Of course, we all know hybrid cloud is a real business need, but the problem is because there was no fundamental consistent experience that could actually implement that. So, as a result, no big businesses have been built. We kind of approach it a little bit differently. We’re very much centered around Kubernetes as a common protocol for compute.

    I think by building on that, I really believe there’s a tremendous business opportunity here because fundamentally, we’re gonna solve these multi-cloud, hybrid cloud and edge computing problems. Those are business problems with Kubernetes as the common compute protocol. So, I think that will keep us busy for the next five, ten years, and I think this business has lots and lots of room to grow.

    Shimel: Let the chips fall where they may. Sheng, we’re about out of time. I wanna thank you for taking time out of your busy day and joining and talking to our devopsy.kinsta.cloud and Container Journal audiences. Always a pleasure to speak with you and get an update on what’s happening at Rancher Labs. I will see you in about a month and a half in Amsterdam for KubeCon.

    Liang: Thank you. Thank you, Alan. It was great talking to you.

    Shimel: Always a pleasure. Sheng Ling, CEO, co-founder Rancher Labs. This is Alan Shimel for devopsy.kinsta.cloud and Container Journal, and you’ve just listened to another DevOps Chats.

    — Alan Shimel

  • Acting Rationally Regarding Coronavirus: RSAC Conference Update

    Acting Rationally Regarding Coronavirus: RSAC Conference Update

    With all the hype surrounding the coronavirus, let’s take a step back, take a breath and not give in to emotional conference mob fear-mongering

    We have all read the headlines: Mobile World Congress in Barcelona has been canceled. Facebook pulled the plug on a smaller conference next month in San Fransisco. IBM Security has pulled out of RSA Conference next week. Health and safety are everyone’s concerns, but are we acting rationally regarding coronavirus?

    RSA Conference (RSAC) put out an update on Friday (use that link to stay up to date on RSAC) with some great metrics on some of the risk factors and attendance numbers. It is also important to note that RSAC is expected to draw a crowd of about 50,000 visitors (some of them attending the DevOps Connect: DevSecOps Days event that we produce).

    Yes, eight vendors have withdrawn from exhibiting at RSAC. Six of these were from China and frankly, given current travel restrictions, probably couldn’t get here anyway. One is from Canada and one from the U.S. (presumably that is IBM).

    But should we give in to emotional conference mob fear-mongering? There is some serious clickbait nonsense being bandied about, including “RSA in Doubt After IBM Pulls out of Conference.”  To be fair, the clickbait headline was updated, but still, that is just fear-mongering at its worst.

    Why would IBM and the Canadian company pull out? Well, two obvious reasons. One is for the safety of their employees and their potential customers. The other is economic if they feel attendance will suffer. But while I don’t have any facts to back it up, I would have to assume that unless the event is outright canceled, vendors pulling out at this late date won’t be refunded their deposits and payments. This is true not only of their fees to RSAC but also of the money they’ve ponied up for hotels, airfare, party deposits, etc. While potential liability for unnecessarily exposing people to the virus could be a legal option, reasonable precautions are being taken. So I don’t think economics play into the decision to pull out.

    As of Friday, RSAC reports that including the members of the canceled vendors, only 0.79% of attendees had canceled their attendance. I would assume that the overwhelming majority of these were attendees from Asia or other impacted regions who could not get flights here anyway. Something like 82% of attendees are from the U.S. On top of this, RSAC is taking additional precautions to keep the conference as germ-free as possible.

    I was in touch with RSAC management earlier last week regarding the DevSecOps event. At that point, I was informed that they were working closely with the City of San Francisco to do everything possible. They are following CDC and WHO guidelines. BTW, CDC still says the impact here in the U.S. to coronavirus is low.

    So, then, are we seeing an overreaction to coronavirus? The security industry, more than the mobile application or other tech industries, is more attuned to risk management. Are we managing this risk adequately? Are we giving in to the fear-mongers among us? The flu has killed so many thousands more people (albeit with higher infection rates), but that has never caused us to shut down conferences or question gathering in groups.

    Personal health and safety is everyone’s own right and responsibility, as well as the responsibility of the authorities. Of course, you should do what you think is best for you and your family. But I think times like this call for a moment of lucidity and the use of the risk management fundamentals so many of us practice in our professional lives.

    Those of you who know me personally know I am a huge Pittsburgh Steelers fan. Their coach, Mike Tomlin, has a saying that I think applies to this situation: “We don’t live in our fears, we live in our hopes.” I hope the current trend of withdrawing from our community is not one that will continue. I refuse to give in to exaggerated fears.

    I do want to announce two things, though, in regard to this coronavirus situation. First, for any conference organizers who have made the decision to cancel their event for this reason (it is your event, your decision), MediaOps is offering a conference disaster program (CDP) that will allow you to use our virtual conference platform and team to take your event virtual with almost all of the features of an in-person conference.

    We have produced more than 10 virtual conferences in the last year or so that have drawn tens of thousands of visitors with hundreds of sessions, exhibit halls, interactive booths, signage, live chat and more. You can go to the home page of Predict 2020, our most recent virtual event, and click “Recent Events” to get an idea here, but just a caution, registration is required. Please see our press release on this for details. It is important that the tech community continues to engage in the very important exchange of ideas, learning and community that is so vital to our success and progress.

    Secondly, Accelerated Strategies Group, DevOps Institute,  JumpCloud and MediaOps are hosting a survey to learn about what you and your organizations are doing in light of the coronavirus outbreak and whether this is forcing you to rethink actions and behaviors going forward—not just for attending conferences, but as part of disaster recovery and business continuity. For instance, is this situation changing your views around working remotely versus working in a large office, going to customer premises or international engagements? Help us gather the information—please take moment and head over to http://acceleratedsurvey.com to answer a few questions.

    As is the mission of Accelerated Strategies, all of the research and analysis will be made available to everyone to use without registration or any payment. Because “knowledge wants to be free.” I couldn’t think of a better example of why that mission is so important.

    “We appreciate being invited to support the efforts of Accelerated Strategies to learn how this global situation will impact people professionally. We know that the JumpCloud community has been impacted, so we are thankful to be able to help in a small way,” said Rajat Bhargava, co-founder and CEO of JumpCloud. “Supporting primary research into the impact of coronavirus across this community is important work, and will hopefully help shape the actions that organizations can take with their teams and business to successfully navigate the future.”

    “DevOps Institute’s mission is to advance the Humans of DevOps and we are obviously concerned about the impact on the thoughts and behaviors of our global community,” said Jayne Groll, CEO of DevOps Institute. “The best way to overcome the hype and adapt to changing times is to collect and share community data.”

    Finally, Mitchell Ashley, CEO of managing analyst of Accelerated Strategies Group, Groll and I sat down for a video discussion of the coronavirus discussion and the reasons behind the survey. The video appears just below. For information, we recorded this just before the news of IBM Security’s withdrawal from RSAC came out.

    [videopress 5RyZpLsG]

    — Alan Shimel

  • EP 1: A Brief History of Testing

    EP 1: A Brief History of Testing

    DevOps’ sister site Digital Anarchist has launched a bi-weekly video series and companion monthly roundtable on DevOps, Automation, CI/CD and testing. Featuring leaders in all of these areas, we explore the challenges and issues software delivery and IT teams face every day. How do we go faster, smarter with better quality? DevOps Unbound!

    The video is immediately below, followed by the transcript of our conversation. Enjoy!

    Transcript

    Alan Shimel: Hey everyone. Welcome to the very first episode of DevOps Unbound. I’m your host, Alan Shimel and joining us for this initial episode of DevOps Unbound, I’m proud and happy to introduce you to James Bach and Grigori Melnik. Grigori, James, welcome to DevOps Unbound.

    Grigori Melnik: Hey everyone.

    Shimel: Before we jump into things, let me give each of you an opportunity to kind of introduce yourselves, your backgrounds, your positions, etcetera, so that our audience kind of knows a little bit, if they don’t already, who you both are. So, Grigori, you’ve already been a guest in our show, so if you don’t mind, I’m going to ask James to go first. James? Introduce yourself. Go ahead.

    James Bach: My name is James Bach. I’m a consulting software tester. I started as a developer in my teen years after I dropped out of high school. I’m the proudest high school dropout you will ever meet. I later wrote a book about dropping out of high school and my particular self-education method, but my big opportunity came when Apple computer hired me to be a test manager, and at the time, I was the youngest manager in the R&D division of Apple computers.

    So that’s kind of something I’m proud of. And I fell in love with testing and I decided to devote my career to testing. I studied the epistemology of testing, the mathematics of testing, the sociology of testing. I am a bit obsessed with testing.

    Shimel: To say the least.

    Bach: And I have a book about that called “Lessons Learned in Software Testing” with a couple of coauthors. And now I teach and consult.

    Shimel: Excellent. And you know what, high school dropout or not, you’ve done pretty darn good, so congratulations and not saying it’s an example for our younger people in the audience to necessarily emulate. Of course, James grew up –

    Bach: My son did better than me. He never went to high school, so I’m –

    Shimel: Really?

    Bach: He’s already outdone me.

    Shimel: Absolutely. Very good. Grigori? Why don’t you tell them a little bit about yourself?

    testingMelnik: Sure. So I’m Grigori Melnik and I am the chief product officer of Tricentis, focusing on building the testing tooling of the future, testing tools of the future. Previously, I guess I spent almost two and a half decades focusing on the developer audience and building all kinds of platforms, Microsoft and Splunk and MongoDB and you know, always been kind of customer obsessed in the sense of developer obsessed quite a bit, making sure that whatever we were focusing on would help drive the productivity and alleviate some of the pains that developers in our target audience had.

    And while a few of those things that I’m particularly proud of, my team at Microsoft was actually the first one that built the very first auto-scaling for what was back known as Windows Azure, now Microsoft Azure, but also focused on common patterns and practices in implementing the crosscutting components that represent crosscutting concerns that later would make into the .NET framework.

    So again, a lot of work identifying those patterns, capturing them, externalizing them, testing them out and then helping drive their use. When it comes to testing, I first kind of discovered it in my days in academia when I was doing research and teaching at university, and it was quite interesting because testing was predominantly viewed through the lens of formal method groups. It wasn’t really viewed as an intellectual activity of discovery, as an intellectual activity of exploring or experiencing something.

    And those were actually the days when I’ve encountered the group of testers from the context driven school of testing, including James and then we kind of kept in touch ever since, even with me gravitating away from the testing more into the developer world and now doing like the full loop of coming back to testing and I have to tell you, I felt, when the opportunity came, I felt that the world of testing, at least from the perspective of how the discipline itself has advanced would be way further developed in the last decade than I found after kind of leaving it for a while.

    So I’m now on a mission of kind of reigniting that whole discipline and putting it more on a pedestal and giving it more view and empowerment and leveling up all around. So, yeah.

    Shimel: Excellent. So, thank you both, gentlemen. And I’m Alan Shimel, I’m the editor in chief, CEO for MediaOps, the folks behind devopsy.kinsta.cloud, Container Journal, Security Boulevard, TechStrong TV, et cetera. And just quickly before we jump into today’s agenda, DevOps Unbound though, today’s focus is on testing. It’s not just about testing. It’s really about DevOps kind of unbound, setting us free, being able to leap tall buildings and bound into space, sort of freeing ourselves of gravity, whatever you want. It’s about speed. It’s about acceleration. Right? It’s about automation in a lot of ways.

    And each – we’re going got be doing these every other week and each episode will focus on particular aspects of this unbound nature, if you will. Today’s is testing. And then once a month, we’re also going to have a roundtable with about six or eight people of Grigori and James’ stature and we’ll open it up to the public for live audience questions and discussion. So I’m really looking forward to that. DevOps Unbound is sponsored by our friends at Tricentis and we thank them for it and with that out of the way, let’s jump into things.

    So, Grigori, I wanted to start off – obviously, you and James take very different paths to our – and both of you have been very successful in your lives and careers. So it just goes to show, there’s more than one way to skin the cat. Right?

    But, let’s take a look – look, I’m probably older than both of you, though not that much I’m sure, but let’s look at the history, the historical context of where you guys come from to be sitting here today and how that, you know, vis-à-vis kind of the whole testing industry, the whole testing, you want to call it a profession, the guild, the whatever you want to call it, right, how has this evolved over the years and let’s put some context in with timeframes. James, when you first went to Apple without saying you’re old, what kind of – what were the timeframes for that?

    Bach: Well, I am old.

    Shimel: So am I.

    Bach: But you’re older, which is nice. It’s nice to be a young guy in the room again.

    Shimel: Uh-huh. I can’t tell you how well that makes me feel, but go ahead.

    Bach: First, 1987, May 21, 1987 was the first day that I ever professionally tested something as a tester. Before that, I was doing videogame development and I had done informal testing, and I hated testing because testing just got in the way of me shipping my product. So, I didn’t like testing until it became my job and then I realized I’m perfect for testing ’cause I love complaining. And I’m much more interested in finding how things don’t work than to figure out how to make them work.

    Shimel: That’s interesting. You know, my background’s in cyber, back then we called it InfoSec, and in InfoSec, most of the people got into it ’cause they liked to break things. Right? Yeah. Same thing. Grigori, how does that timeframe-wise and everything else, how does that match up with your own experience?

    Melnik: So I like to actually build things. _____ you guys who are breaking things. And occasionally I break things and actually this also speaks about this overall I guess optimism of most developers who think that what they write is perfect and always underestimate the amount of buggy code that we put in there.

    But to me, if I think about my first day when I actually had my job as an engineer, actually, it was September, I think 5, 1990, so a few years after James and at that time, I was actually writing a C-library for a PC converting the data from mainframe into the visual format and I had to deal with all kinds of quirks of Fortran and the 80 characters limit and the asterisks for, you know, for bringing – the continuation of the line, all kinds of exciting stuff. But back to the beginning, to make sure that I don’t go too far on the tangent, we actually didn’t have, for a very, very long time – again, I’m giving you my angle into the testing, if you will.

    We actually didn’t have a dedicated thinking about testing as an activity, as a pursuit of excellence. It was just something that you kind of were doing and then at some point later, you’ve heard and learned that oh wait, look, there’s a QA department, apparently, right? And they’re the ones that were mostly viewed as gatekeepers or police of some sort. Right?

    And then again, if I think about again, once I got more into the research and academia and studying testing specifically because, you know, I’m probably one of the very few people who has testing in the title of my PhD dissertation. But, I remember looking back and thinking, “But where does this come from?” Right? Where did actually software engineering come from?” Right? And of course, this is where the history of the conference deck, you know, after the _____ _____ where all the stalwarts of at that time computer science and well, not even computer science, mathematics departments because that’s who were doing all the programming back then at the point the software engineer discipline and later on the association of debugging, right?

    It was the infamous story of how the moth was found in Harvard University’s scientific lab and the term bugging, you know, was coined. I almost think like the – in the early days, it was very much associated with this era of debugging. Right? Then later on, the era of the ability to demo, the fact that the software was matching the stack or the requirements, I think it almost feels like there were at least a decade when people were fixated and some would argue that it still continues.

    Shimel: What decade was that?

    Melnik: Hmm?

    Shimel: What decade are you referring to?

    Melnik: The debugging or the – the debugging I’d say –

    Shimel: Are you talking about the 70s? Are you talking about the 60s? Are you talking about the 50s?

    Melnik: I’m talking about 50s and 60s. I’m talking about the 50s and 60s as almost the era of debugging the way I viewed it. Then, after that, the era of more like 70s and 80s where you were focusing more on matching the spec and demo and that the software would actually approve it. And this is where this big, big, big focus was on formal methods and trying to even mathematically prove that a software worked according to the spec.

    And then after that, I feel like the next era was the era of breaking or, you know, something that probably is still continuing. And again, all these elements I feel are present in today’s profession of testing, but the later years, the last 20 years was everything that I was kind of studying, watching from the sidelines, getting myself into. I like to call it the era of enlightenment, if I may. I know that’s super pompous of me, but this is where I view more testing in the way how James and other members of the context drew in school of testing had formulated it which is, you know, lighting the way for the decision-maker, not for the developer necessarily, not for – again, it could be for the developer, but somebody who at the end of the day makes the decision whether what is being produced is acceptable or not, or if it’s good enough to ship. Is it, you know, what risks associated there and informing me as a decision maker about all these different factors and then leaving that decision up to me.

    So the testers are not the police. They’re not the quality gate. They’re not _____ anything. It’s really up to the stakeholder who is commissioning all this effort and who makes the ultimate decision about releasing something, putting something into production.

    Bach: I’d like to offer some historical notes on this.

    Melnik: Please.

    Bach: Okay, first, are you aware what the first book was on the subject of software testing, the first known book? A little quiz for your Grigori?

    Melnik: Is it the Myers book?

    Bach: It’s before that. It’s Program Test Methods from 1972 by Bill Hetzel. Now that book was a report on a conference a testing conference which was the Chapel Hill conference, which happened in ’72. That seems to have been a historical watershed event in testing. Before that, the first chapter on software testing that I’ve been able to find was written in 1961 by my teacher, Jerry Weinberg, who wrote it when he was 25 years old. It’s a brilliant chapter on testing.

    What’s fascinating to me is how differently Weinberg talks about testing in 1961 compared to how they talked about testing in 1972, although there is a reference in the 1972 book back to Weinberg, praising Weinberg’s attitude about testing. It’s fascinating to read that because the book in 1961, it’s Computer Programming Fundamentals and the chapter about testing was written by Jerry, he told, although it said it’s co-written, the book’s co-written with Herbert Leeds and Jerry Weinberg, but Jerry wrote the chapter on testing.

    And Jerry talked about testing as a matter of imagination, not automation, as a matter of being suspicious and critical, as a fundamentally unalgorithmic process. And he develops this beautiful story in his chapter about a programmer who’s sure that he’s found the last bug and then finds out that he’s wrong. And then he adds another check for that.

    And then he’s sure now he’s found the last bug and then he sees something else go wrong. And Jerry’s conclusion is look, this is just, we’re working on complex systems and this is always going to be like this. Now, Jerry was on the first project in 1958 that ever had a dedicated test team.

    Now, the reason why he knows that is that in 1961, IBM held a conference of all the computer programmers in the entire world of which there were 400, apparently, and Jerry said his team went to that conference. He was at IBM at the time, and he said everyone thought they were crazy ’cause they had a dedicated group of testers and no one else did.

    They all were just testing their own stuff. So it seemed like the idea of having a dedicated test team caught on and then in 1972, the way they talked about testing was all about test cases, automation, formality and that kicked off the era, I think, of the factory, the test factory. We can have technology and we can have procedures that make it so you don’t rely on human thinking.

    So this goes against what Jerry Weinberg was preaching, not only back in ’61, but all through his career, I became a student of Jerry’s in around 1989 and took all his classes in the mid-nineties and he became a mentor to me. That’s why I’m a real acolyte of Jerry Weinberg, because he always put the human in the center of everything. But, testing – when I joined testing, all the testing textbooks were about how you have to define test cases and if possible, automate them.

    And I felt like that was a fool’s idea. I think, well, the problem is is that there’s too many things to define and far from being unbound, we’ve become super bound by all of these documents and all of this code. And so if you want to be unbound, we have to find a way to temper that. We have to find a way to interact with our tools so that we’re not constrained too much by them. And that, in the nineties, the urge to unbind ourselves from that waterfall world and that heavy documentation world created agile, but it also created the context driven school of software testing, which is a humanist approach to software testing.

    And that was in the mid-nineties that we started creating that. And then DevOps and agile continued to sort of take over the world except that it seems to me that agile in a lot of places has lost it’s humanist foundation and it’s turned into tools, tools, tools. And so if we’re going to really talk about Unbound, DevOps Unbound, it seems to me that we have to be specific about what is it we’re unbinding. I hope what this means is it’s people being unbound, using DevOps as a tool rather than –

    Shimel: But not just a tool. I’m sorry. I didn’t mean to jump in. But not just – you know what, James, we don’t want to make the same mistake that Agile made. And you just said, one of the problems with Agile is we went from humanist to tools, right, too much of a reliance on tools. Let’s not make the same mistake in DevOps. I think that’s something I’ve advocate for for a while too is we can’t lose the human in DevOps.

    Bach: Actually, I want to hear you say more about that, Alan, if you’re willing to say a little more about that.

    Shimel: I’m not shy. I’ll give you my two cents. Look, I started devopsy.kinsta.cloud. I cover this place. I cover this area pretty heavily and I have for seven or eight years now. And I think there’s been this – and I don’t want to say agile failed ’cause agile is far from a failure. But there has been a reliance on tools and maybe overly processed. When we think about things like ITIL and ITSM versus DevOps, let’s say, right, we get in – we tend to point fingers at ITIL. Excuse me and ITSM _____ too much process, too heavy, too much of that, that whole change management thing.

    But there are good things there. Nothing’s all bad and all good. The world’s not black and white. It’s grey. Right? And so there are things we take out of ITIL and things and ITSM that we put into DevOps. Btu DevOps, to me, anyway, and it’s just my humble opinion, is fundamentally about people and teams and culture, not the tools- there’s a lot of tools we could use and there’s overlap in tools and what’s the best tool for any given job.

    We could fight about it till the cows come home, but at it’s nitty-gritty, DevOps is making sure that devs and ops and tests and security and these people work with a higher degree of communication, right, with a higher degree of cooperation getting jobs done faster. And we do that by adding things like automation to the mix. But automation for automation’s sake alone is not enough. Right? And to do automation, yes, you’ve got to use tools sometimes to make that automation work. I get it. But if we lose the fundamental aspect that DevOps is, at its core, about humans, I think we all – we lose what DevOps is and I don’t hold myself out to be as accomplished as either one of you, but I –

    Bach: I still love you, Alan. I love what you just said. I think this is – if you can hold on to what the principle and the feeling behind what you just said, we can do anything with tools and we’ll be okay. We’ll be okay. If we’re talking to each other, if we’re caring about each other, I keep seeing people losing that and of course, any technology and any methodology, when it’s applied sociopathically, will become abuse. And so we just – those of us who can, shall do – should do whatever we can do keep it non-abusive and keep us talking. And then I think DevOps can be a wonderful thing.

    Shimel: Absolutely. I’m sorry to take us down that. Go ahead, Grigori.

    Melnik: No, it’s super encouraging to hear what you said, Alan and again, I’m a very big believer into the greatness of human mind, but it feels to me that in this kind of history of our industry, the pendulum keeps swinging back and forth, right? remember the whole infatuation with the case tools, you know, back in the eighties and nineties and then later on, there was this whole big movement of the software factories, like the term was actually software factors where the idea was that you can go and abstract away at some high level and then the loop, y, the tools will generate all the code and everything for you and make it all highly maintainable, all that, and of course that failed too.

    But I think out of this desire for some reason to do – to come up with the sort of boosters. So I don’t know, some kind of the way of equipping the humans to deal with the inherently complex problems where today there’s no better mechanism of dealing with them other than human brains. So this whole vision of, you know, computers writing computer code, I mean, that’s been promised in the first era of AI, not today, but I’m talking about the sixties, right, and seventies were all –

    Shimel: Yeah, yeah, I mean Spielberg does pictures.

    Melnik: Then it kind of died out. Right? Same thing again, you know, having the computers entirely come up with the test strategy, the thinking about testing automatically, entirely automatically, I think is – I think it’s utopical, at least if you think about what the tools are capable of doing today and for a very, very long time in the future. I think the human will remain to be at the center of this activity, while again, all the tooling is great because tooling gives you additional powers and additional ways of perhaps automating the most rudimentary, the most, you know, boring elements of the job and lets you actually free up time to think about new theories, new hypotheses, new models, new approaches –

    Bach: But you’ve got to consider different kinds of tools. Like, have you noticed the difference between let’s say a tool like a programmer’s IDE. When I use a programmer’s IDE, I don’t feel oppressed. I feel empowered. I feel like I’m riding a magic carpet and I have laser cannons mounted on it. I feel wonderful. But when I use most testing tools, I feel oppressed, like I have just a few possible things I can do and if I have any –

    Shimel: Like you’re castrated.

    Bach: that’s outside of what the test tool designer has thought that I might want to do for testing, then I’m not allowed to do that. This is what I feel like when I encounter something like Cucumber, which is very restricted and the Gherkin language, it’s very restricted. It’s stopping me from going on flights of imagination. And yet, when I use the tools that programmers have created for programmers, unsurprisingly, programmers have created for programmers tools that make them feel powerful and free and able to do all kinds of wonderful things. I would like to bring the same sense of freedom to testing that programmers already enjoy. That’s part of what we’re doing with the transformation work we’re doing at Tricentis.

    Shimel: Yeah. I love that.

    Melnik: In all fairness, not all of the programmer’s tools are that liberating. Some of them feel like you are operating in a straightjacket too, but in general, at least there are some examples, there are instances of tooling that are widely accepted, widely adopted today that are supporting and kind of accelerating your abilities to do your job without constraining you. That’s for sure.

    And you know, the piece that James was alluding to, this is actually the new initiative, that we are driving inside Tricentis, you know, about mentioning this whole new platform of the test tools for the future where we are building something akin to the IDE, we’re actually not calling it IDE, we’re talking ITE, integrated testing environment where actually it’s the human being, the human tester who is in the very, very center of the ITE, and all these other snippets and utilities and services and everything around the human tester, around the human that manages to support the individual in the way, wherever his line of thought, line of exploration, line of test execution may lead to. Okay?

    So yeah, we’re kind of envisioning this to be as a super configurable kind of morphing tool, almost like the chameleon style. We’re depending on the context and the environment, the different capabilities of the ITE, the integrated testing environment will represent themselves and then the human will actually pick whether this is actually something that they want to take advantage or not as opposed to again being forced into a specific kind of mold or one way of doing testing. And I don’t think – we don’t think actually anybody has attempted something of this caliber, specifically in the space of test tooling before. That’s why we’re so enthusiastic and so passionate about this project. Aren’t we, James?

    Bach: Yeah. I also don’t think that anyone is going to be able to copy is easily because the only way that they could actually compete with us is by hiring someone who loves testing, which test tool companies hate doing because testers are troublemakers. I still can’t really – it’s hard for me to fathom that Grigori really knows what he’s done by hiring me because I’m a constant gadfly.

    Melnik: [Laughs]

    Bach: I’m constantly complaining about the state of test tools in the world and at Tricentis, frankly, and I want things to be fundamentally better, but that means we have to fundamentally change how we think about what is a tester. Which might get us into the role of testing a bit, but the – to me a tester is a puzzle solver, a problem finder. I’m not a button pusher and I’m not a verifier. I don’t verify things. Tools can verify things. I’m not looking to prove that something works because I can’t prove that anything works. What I can do is collect evidence and then draws inferences from that evidence with a critical mindset.

    And of course, lots of tools are collecting facts about the products that I’m testing and those – that can be automated and so we’re pulling in these facts. And we can say, “We got this output and we expected to get this output, so apparently there’s no problem here as far as we can tell so far.” But then the tester layers onto that a critical mindset saying, “But how do we know and how can we be fooling ourselves?”

    And so I’m bringing that mentality into Tricentis and I’m really surprised so far they’ve been actually quite welcoming of me, but for years and years, I’ve tried to help other tool companies with this and basically, you know what reaction I get? They basically say, “Well, our customers just want to have automation that just pushes a bunch of buttons and we don’t really care about test design. We don’t really care about empowering testers. So that’s not going to help us make any money, James, so we’re really not interested in supporting the skilled testers that you keep talking about.” So Tricentis has a different kind of vision that I think is hard to match.

    Shimel: There’s also a little bit of you can’t make wine before it’s time. Right? And I think right, I think you need the right macro conditions, that things like DevOps have brought about and the whole progress -0 we’ve gone back here now to the fifties and sixties and all the way to the present time.

    Certainly the world we live in today may be a – I want to think so anyway, we’re a little bit more open to the idea of saying, “Look yeah, we can automate some stuff. We can have – we don’t need a human to just push buttons. Right? We have tools that can go push the buttons for us, but we need humans to do blank. We need humans to do some of this stuff and so we need to enable and empower them to do that within the context of let’s automate what should be automated, let’s say. But we still need those humans in there.

    You know, when I was growing up, much like you guys, right, the only animal in the world that used tools was humans. Isn’t that – that’s what I learned in school, right, that’s what separated us from animals, one of the things, right, was our ability to use tools. Well, then we found out chimpanzees use tools and other monkeys use tools and we still were okay with that ’cause they were primates. Now we found birds use tools, right, to crack nuts and stuff like this.

    So tool use in itself does not connotate one’s intelligence or higher being. We need to – so to me, that’s the ultimate case. Right? It’s not about what tools we use. It’s about how we use our brains. And I think that’s apropos to what we see in testing today. Yes, we could come up with tools, but it’s creating an environment for people to think in and use their brains in and apply it that I think will ultimately provide us the highest payback, if you will. Right?

    Bach: It’s interesting what you just said about you’re implying that the history of how we got to where we are now is important, that we have to have a certain set of – a certain historical context, technological context in order to take the next leap. And I think one thing in which that’s really true is we now have decades as an industry, decades and decades of experience trying to eliminate people from engineering and we can’t do it. I remember, maybe you do, there were these advertisements in Byte Magazine in the eighties about case tools and all your marketing people can just define your product and you don’t need developers anymore because it automatically generates all the code.

    And I remember sitting there at Apple Computer reviewing case tools, advertisements that had been sent to me, thinking, well, could I buy some of these tools and actually use them to help with the testing? And it turned out, no. You couldn’t. It was just all – it was all hype and nothing. And so I shrugged. And so a lot of – and even today, now we have AI, AI is the new case tool and the AI will do all this stuff for you. Then it turns out the AI is biased and racist and confused and if you put kitten ears on a whale, it says, “That’s a kitten.”

    Shimel: Yep. And it’s no more than ML, the machine learning anyway, but you know, yes, we’ve been – we have been, you know, chasing this white whale for most of my adult life and at the same time, if it was a nation, the fastest growing nation on earth are developers. There’s 40-something million is the estimate growing what, 20 percent a year or something like that. So I think it’s time we stop probably chasing that white whale and move on to empowering people.

    Bach: And one way to do that, I suggest a definition of programmer or perhaps developer. And the definition I use is a developer is someone who stands at the gateway between the world of the machines and the world of humans. And the developer’s purpose is to operate competently in the world of people and then operate competently in the world of machines.

    And if you don’t have that person standing at the gateway, then you don’t have a connection between the world of humans and the world of machines. You just have people kind of praying to the god of technology and hoping that good things happen. And so no matter how complicated technology gets, no matter how much AI we have, we still have the need to operate competently in the world of people and the developers will always live right at that threshold. And testers need to live there too and not get mowed under by automation.

    Melnik: Yep.

    Shimel: And you know what guys, we’re almost out of time, but this also brings up something that I thought we might be able to get to on this show, but we’re running out of time, and that is that this caste system, if you will, caste system of developers being a higher caste than the tester who’s higher than the, what we call today the SRE, the ops person or what have you. And this whole IT stack of humanity, I think we need to examine that too with the develop – when we’re asking the developer to do the security and the testing, is he any better than the tester? Is there a difference? But we’re going to save that one I think for another show, if you guys would like to come back on, and we can explore that a bit.

    Melnik: _____ back, but I categorically reject that whole hierarchy and I also do not like the whole, you know, notion when people say, “Hey, but the tools and everything that would really help with the low skilled tester.” That’s another notion that kind of gets _____ _____ –

    Bach: No, we reject that.

    Melnik: So annoying and, you know, whether it’s development or testing or any other, you know, data science modeling, the UX design, it’s the discipline, it’s something that requires dedicated effort of studying, perfecting, thinking about the way how people do that work and it requires intellect. That’s the most important thing. You know, using some very powerful tools doesn’t give you the license to turn off your brain and I’m happy to come back on the show and talk about the different career letters and progressions because again, it’s going to take us a longer –

    Shimel: That’s a whole other show.

    Bach: There’s a lot to –

    Shimel: _____ and vocal about that.

    Bach: say about that. But I just want to note that this whole issue has been studied in great depth in another field, in the field of the sociology of science. For instance, in physics, theorists are in the higher caste and experimentalists are in the lower caste. So if you’re an engineer, you’re in the lower caste and they’ve studied this. How do these people cooperate? How do they assign prestige to each other? It’s a well-known phenomenon in many fields of human endeavor.

    Melnik: And the same in math, right, the theoretical math versus applied math, the theoretical math seems to always think that they’re the gods and they’re the ones that are, you know, creating something that, you know, will take centuries for the world to truly appreciate and then you guys are in the applied math solving the problems of today.

    Shimel: Exactly. Guys, we’re out of time, but I’m going to hold this – I’m going to hold you both to it. We’re going to come back on – not in the next show because I think we have something scheduled, but in one of the ones coming up, we’ll have you both back on, or maybe this’ll serve as part of our first roundtable in about a month from now when we’ll open it up to the audience as well. But for now, Grigori, James, thank you. Yes

    Melnik: Thanks, Alan.

    Shimel: James, thank you.

    Gentlemen, it was a pleasure. This is Alan Shimel. You just watched the very first DevOps Unbound. We’ll be back in two weeks with a fresh panel, fresh topics, stay tuned. Thanks again to Tricentis for sponsoring and thank you for watching. Bye-bye.

  • DevOps Chats: XebiaLabs/CollabNet Version One Merger Executive Discussion

    DevOps Chats: XebiaLabs/CollabNet Version One Merger Executive Discussion

    In this special DevOps Chats Video Edition we dive into the XebiaLabs/CollabNet Version One Merger. Joining us for this video discussion is the CEO of the new company, Ashok Reddy and President and former XebiaLabs CEO, Derek Langone.

    Ashok, Derek and devopsy.kinsta.cloud editor-in-chief, take a deep dive into the reasons for this merger and what it means in the end-to-end DevOps market.

    Have a listen for some great background on this merger and what we can expect to see in the market soon. Below is the transcript of the conversation if you would like to read along.

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel for devopsy.kinsta.cloud, and you’re listening to another one of our—actually, our video DevOps Chat edition. Thanks for joining us.

    We have a great DevOps Chat video lined up for today. As many in our audience know and in the DevOps community, last week was a pretty exciting week with continued consolidation in the DevOps space. The big story was a merger, acquisition, private equity—I’ll let them define it, but the joining of XebiaLabs with the CollabNet VersionOne team, financed by a private equity company. And then kinda the surprise cherry on the cake was the addition of a CEO, a pretty well-known name to us in the DevOps community for both his days at IBM, CA/Broadcom, Ashok Reddy, as CEO. And we’re lucky enough to have Ashok Reddy, CEO of the new company. I’m gonna let Ashok handle the name.

    And joining Ashok is a friend of ours who needs no introduction in the DevOps space, our friend Derek Langone. Derek is the CEO of XebiaLabs, you know, one of the main companies in this merger, and Derek will be the president of the new entity going forward.

    So, Ashok, Derek—welcome to DevOps Chat. Thanks for joining us.

    Ashok Reddy: Thank you, Alan. Great to be here. Thanks for inviting us.

    Derek Langone: Hi, Alan.

    Shimel: Yeah—no, it’s great. Okay. So, guys, let’s jump into this. Ashok, as I said, you need no introduction in the DevOps space. You’ve accomplished, between mainframe and DevOps and IBM and CA, you’re an accomplished executive in this space. What motivated you to come on board here as the CEO of this new entity, and also would you mind—I don’t even know, I’m not sure what to call the new entity. Should I call it Xebia, CollabNet, some Newco? I’m not sure. So, go ahead.

    Reddy: Yeah, so start with that. I think we are working on, obviously, we’re doing a branding initiative. We’ll be coming up with a new name shortly.

    But as well, Alan, I think in terms of, you know, why did I join this is, it’s really, in the past, if you look at what I personally have done is focused more on transforming existing businesses, very large businesses, whether it’s in the Mainframe or in the large existing portfolios, and I think that was very good in terms of what I did there.

    But what I found here with TPG, as a private equity firm, which is very well known for transforming, the investments they make are really transforming industries. As examples, TPG was an investor in Spotify or Uber, an early investor in Airbnb and some other companies like Chobani and others where, they’ve kind of transformed the industry. So, when they had this thesis around DevOps is one of the most important transformational things going on in the industry, and there’s really, it’s not just a consolidation, but really, coming up with a true platform all the way from end to end, from how do you define value to how do you measure value and how do you plan and track and deploy and secure?

    To me, it was more of a sort of just transforming existing things to build out a new platform with, starting with some of the best of breed companies, right, technologies. So, to me, that was really what the attractive part is. Plus, you know, we can define—there’s no boundaries in terms of which industries and customers we want to, but really, truly focus outside in from the market perspective, and every company is becoming digital, everybody talks about that, but I don’t think we have a platform which really provides that.

    So, I think that’s really why I changed. And also, you know, in terms of the naming, as I said, we are still working on something which is, represents the broader platform we are building and not just the things, what we have today.

    Shimel: Fair enough. Derek, I’m gonna ask you a slight—I’m gonna ask you the same kind of subject, but slightly different. Hey, man, you’re CEO, you know, you’re the boss, and now you’re president of the new company which obviously still covers a lot of territory, a lot of responsibility. But, you know, as an organization, why did you feel it was best for Xebia to do this, and then you personally, right? Is this—where do you see, you know, what gets you excited about your role in this new adventure?

    Langone: Yeah, so, I’ll try to answer that a couple ways, Alan. First, from a business perspective, why this made sense—I mean, as you followed our progression at XebiaLabs over the years, you know, we’ve established ourselves as a premier vendor to large enterprises and helping them, you know, sort of realize real release orchestration and deployment automation and now reporting on important aspects of the software life cycle.

    And we’ve been able to gather meaningful clients, you know, the largest banks, insurance companies, airlines, health insurers use our platform because it’s so scalable and so robust. However, the feedback we got from customers quite often was,  “Hey, you know, you really only own a small slice of my life cycle, and what is sort of adjacent to you is a tapestry of individual tools that we’ve woven together, and it would be great if you had a wider footprint.”

    So, the opportunity with TPG, looking at the market, and the opportunity at the very, very top of the market in the Global 5000 to create an enterprise scale platform gave us the chance to consolidate with CollabNet VersionOne to put two best of breed technologies together to have much more of a horizontal influence on the software life cycle and the power of those two pieces together really does give you that formula of one plus one equals three or greater. So, that was what was exciting from a business perspective.

    For me personally, it’s terrific to be able to have Ashok as a leader in our organization and someone that I can learn from. And you’re absolutely right, I’ve been the CEO, so I’ve sort of been the boss. However, I’ll tell you, it’s an easy transition, for two reasons. Number one, Ashok’s a great leader with an incredible track record and a skill set that I would like to learn from. And then, number two, I haven’t been the boss at home for many years, so it was sort of an easy transition to not being the boss at work.

    Shimel: [Laughter] Amen to that, brother. I’m with ya. We won’t tell anyone—no one’s listening, though, don’t worry.

    So, we’ve got this new entity now, which represents the assets of CollabNet VersionOne, XebiaLabs kind of put together. Ashok, you mentioned sort of best of breed technologies within their places.

    Let’s lay it out for our audience, right? Where are the strengths of this new entity? Where is the best of breed functionality? You know, when we look, I call it the end to end DevOps kinda market, right, the players who are trying to do end to end DevOps. No one has the whole enchilada yet.

    But as you sit here today, gentleman, where do you see the strengths? Where are the real assets of this new entity today?

    Reddy: Yeah, no, I think it’s—so, let me start with, you know, when you start with the overall, it’s really, the focus is value stream management, for example. Companies who look at how do I measure value; how do I look at agile? From an agile planning perspective, I think there is, VersionOne is best of breed in the sense it was built ground up to be almost like a reference architecture for the same framework. If somebody is adopting the new, say, 5.0, for example, updated where it’s got value streams and how do I drive value streams—it’s actually built for it. All the way from how do I blueprint things to how do I create epics and stories to be able to plan and do the resource planning?

     So, that’s one aspect of it, but then the second part is, even with CollabNet, you know, people kind of forget CollabNet started many of this open source movement around Subversion and it’s, 35% of the market today still uses Subversion.

    But the Git part, which is where I find not many people know that, but you have Git which is secure Git. Because many times, there is many vectors, the three security vectors in enterprises—if you used distributed Git, you don’t get. And something like CollabNet actually has implemented really strong security protocols and a centralized way of managing, so you can actually manage Git in a centralized way with secure. And the people like Intel, you know, tens of thousands of people use it.

    So, you have a system of record in agile planning and resources to the source control and version management in CollabNet and in the TeamForge SCM, which is a part of GitAgile. Then, of course XebiaLabs. I mean, I think, you know, we competed with XebiaLabs in the past, but it’s really in terms of how XebiaLabs was, you know, both from a release automation to release orchestration, because it can do it without actually having scripts and people—scripts break in a transformation. Things change. The technology is platform agnostic. It can run on any cloud, supports on any cloud. And just being end to end, and now they have complete visibility with AI and machine learning.

    So, I think those are the three elements which I feel like are the best of breed. And then there are some things which we, you know, obviously, we’ll organically develop and then we’ll acquire other best of breed technologies. But I would say those are the strengths is connecting all the way—it’s not just orchestrating releases, you can now orchestrate business outcomes in a very agile fashion.

    Derek, did you want to add anything else?

    Langone: Yeah, I think, Ashok, you covered most of it, and you also said something important, which is our goal, to be that software life cycle system of record.

    But really, Alan, if you look at these two pieces together, what VersionOne has done for the engineering side of software life cycle, giving you that velocity and that sort of iterative agile approach. We’re trying to apply to the entire software life cycle. So, take those principles and apply them to release orchestration, deployment automation, and collect data along the way to be used for value stream, for compliance reporting, security reporting—things like that.

    So, essentially, create this platform that does a couple of things—gives you the ability to increase your velocity, scalability and so forth in your software factory, but the important element to understand about our approach is, even though we’re building an end to end solution, it’s going to be reliant on its integrations with all the best of breed tools that have already been invested in by these big organizations, right? So, I won’t name tools, but they’re very common CI tools, planning tools, provisioning tools, ITSM tools. We have all those integrations built out of the box. So, we leverage all of those investments as part of the process, so we’re not displacing any technology. Quite the contrary—those technologies come along with our process, and it allows them to be a part of the solution of that system of record validation for software life cycle.

    Shimel: You know, and I think it’s worth mentioning—many of those tools, Derek, are actually open source projects as well, right? Because open source plays such a big part in this.

    You brought up, what both you and Ashok said here brings up kinda two thoughts in my mind. Number one is, no one just wants a collection of disparate tools. We all want things that work together, right? And Xebia actually—truth be told, I’m much more familiar with XebiaLabs than I am with the CollabNet VersionOne suite. Xebia did a great job of integrating with open source tools, right, as well as third party tools.

    I wasn’t aware of a XebiaLabs CollabNet VersionOne integration, though. Are there any? What are the plans for them? Let’s hit that first and we’ll go from there. I don’t know if that’s an Ashok or a Derek thing, or maybe it’s too far in the weeds.

    Reddy: Yeah, we’ll—I think I’ll just say that, you know, as far as from a VersionOne and CollabNet perspective, I think there has been, I think, as you said, XebiaLabs has done a fantastic job with this periodic table type of things, tools in the DevOps tool chain. So, as part of that, the whole integration on SCM, the Git with CollabNet’s support for the GitAgile, there is already integration.

    There are some things in terms of more of API level integrations between VersionOne and a couple of the other things at XebiaLabs, but we are now strengthening that. But Derek, you may have, you know, some things based on what we have done in the past with Xebia and the CollabNet VersionOne that you may want to add other things.

    Langone: Yeah. So, Alan, to your question about the integration that exists today between CollabNet VersionOne and XebiaLabs—that’s been a long standing integration. We have several customers in common that have benefited from those technologies together, and frankly, that was one of the validation points when we decided to become part of this merger, that we had already seen customers benefit from these two technologies together and felt like if we did that in a more purposeful way, we could built out a higher degree of value for these customers and benefit ourselves by expanding our functionality on sort of both sides of the balance sheet.

    So, I think you’ll see much deeper integration and a lot of our opportunity to build out that value stream thesis by building these bridges to other products, including, you know, these two companies’ products, collecting that data, and then providing that data for these purposeful value stream management reports.

    You know, I look at it from a couple of perspectives. The data that we are collecting from all the tools in the process is used to give high degree performance measurement metrics, KPIs, things like that. Some of the unanswered questions that CIOs have been struggling with for years are, “Hey, I’m spending $500 million a year on Devs,” and now, for the first time, they will have that. And then, for really practical reasons, a lot of these customers that we have—big banks, insurance companies, airlines are heavily regulated, so we’re able to give them chain of custody reporting, compliance reporting, security reporting, testing coverage. Things like that, that have largely been unanswered questions for years.

    So, I think the power of these two technologies together and that deeper integration will only serve to provide more and more value from the information we collect.

    Shimel: Excellent. So, guys, excellent answers from both of you, and I understand what you’re saying. I think one of the—it’s sort of a, you know, this balancing act that we’re seeing, maybe it’s because it’s early in the game for the end to end DevOps provider. Because on one hand, you have to be open—you know, you have to be able to integrate with this whole multitude of tools that have grown up, some open source, some not, within that DevOps end to end software development and delivery life cycle, right?

    You know, so that’s out there, and if my hands go off the screen, I apologize. But at the same time, part of the allure, part of the benefit that we would get with an end to end DevOps solution is that, maybe I could use less. I don’t have to have all of these different tools that I have—I have one suite, one platform, right, that gives me a lot of it, right?

    And I understand, Derek, you framed it well, and Ashok, I know you’re familiar with it is, there’s this balancing act of, you gotta play nice with everyone. Because all of these companies are using all of these different tools, but at the same time, you know that your end game has to be, “I’m gonna try to give you as much as you can from one provider.” Is that—you know, and it’s a tough balancing act, frankly.

    Reddy: Yeah. No, I think, to me, if you look at the DevOps landscape—yes, there are, some of the vendors would say they have built out a single application or whatever. But the reality of it is that, you know, we can actually do the same thing with the type of capabilities from planning to tracking to SCM and, you know, some of the release, and as we buy other companies. We build it out, it’s completely integrated, and we make that work, right?

    But the only thing is, it’s, in enterprise Global 5000, many people already are using different things, and it’s, what’s an application in an enterprise? It’s typically a multi-tiered application. Some of it will be, you know, maybe an Android aspects, there will be a mobile app in iOS. So, you have to use Xcode, you have to use Git for something, you have to use Jenkins and you may have to use now, in a multi-cloud, Spinnaker.

    So, I don’t think there will be a choice to just use something from one vendor on everything. But even if it did that, we are saying that we can still provide that entire end to end from one vendor, or you actually have an option to replace parts of it because you’re already using something, and things get updated, even open source. You said open source is everywhere, and it’s going to continue to change because of innovation. So, accommodating that, and then, is it compliant, is it secure? That’s a big aspect of it.

    And one other thing which I think is important, Alan, is it’s not—you know, from a DevOps and agile perspective, it’s not just about the tooling and the end to end. It’s really about the transformation and the cultural parts of it and coming in with more of agile cultures and others, which is what we do a lot, and customers start with that. You know, people can use all sorts of tools, they deploy a thousand times a day, but that doesn’t get them the business outcomes and how do I transform them to work? To me, that’s another aspect of it which we are to consider. Even if you have one tool, how do you change the culture, how do you get people to change in a constantly changing world?

    Shimel: Absolutely. Guys, I’d like to move in a different area, if it’s okay. We’ve spoken about sort of what the market looks like and what the strengths are. You know, we wouldn’t be fair and balanced if we didn’t talk about maybe what the weaknesses are or where. And I don’t mean weaknesses, but where—where do you see places where this new entity can improve from the current lineup? Whether it be building organically or buying, right? You know, it was—at the announcement of the merger, it was made pretty clear that this isn’t gonna be the last acquisition or merger, that there were funds set aside for more acquisition activity. I assume you’ll also be building holistic additions to the platform in the suite.

    In what areas can we expect to see additional functionality added here?

    Reddy: Yeah, I think it’s a great point. I mean, we—I mean, you start with the life cycle. I mean, obviously, in the front end, you know, we have the whole notion of planning and then how do you actually track things and how do you deploy. But then, you know, the quality is a big aspect of it, right? The whole continuous quality, the continuous testing is something we obviously can integrate today with many of those things, other products and open source technologies. But if you think about from a platform perspective, I do expect, you know, some sort of continuous testing and quality as a key aspect.

    The other one is, you know, security. Because I think, especially with applications and the more and more data driven applications, security is a key aspect. And some form of more feedback—we have some feedback loops built into every aspect of our platform, but I do say from a customer experience monitoring perspective, being able to bring in some of the feedback loops is important.

    So, Derek, do you have any other thoughts in terms of the various areas we could improve based on some of the customer interactions you’ve been having?

    Langone: Yeah, Ashok, I think you hit on the fundamental part to DevOps transformation. So, I think that, you know, we’ve got an eye towards that functionality, and whether we have, you know, sort of an inorganic, acquisitive approach to that or primarily a partnering approach. I think we’ll continue to kinda round out that functionality.

    And again, it has to dovetail back with our thesis. We are building a platform for the enterprise that has all of the elements required of enterprises, right? These businesses are heavily regulated, so security is front of mind, quality of what they release out to their customers and consume internally is top of mind, right?

    So, again, when we look at how we build out this platform, there’s gonna be a few elements to it, but it will all be towards the approach of giving best of breed functionality and then always staying open, because we are gonna have to work around investments that have been made in the enterprise.

    So, we recognize that this is not the end of the story and we’re moving aggressively to round out the story from a product and messaging standpoint, and that’ll be an endeavor that happens in earnest throughout the rest of this calendar year.

    Shimel: Fantastic. I’ll just add one thing to that—Ashok, I long for the day that when you say, quality, we mean security. Right? Security has to become synonymous with quality, and then, hopefully, we’ll really start achieving what we need to achieve in security—not just in DevOps, but in IT in general, and in business in general.

    Guys, I wanna thank you. We’ve only got a few more minutes, here. I wanted to just kinda bring us towards our end goal line with this thought and get both of your opinions on it. You know, you’re talking to the devopsy.kinsta.cloud community. It’s probably the largest singular focused community on DevOps in the world today, worldwide, right? It’s a worldwide community. I want you to look in the camera and talk to the audience. As DevOps practitioners, why should they care? Why is this new entity important to them? Why do they need to take a good look at this?

    Reddy: Yeah. I mean, I think, you know, part of the—I mean, I’ve worked with the DevOps community for many years now. And I think, you know, I find they’re really the, what I call, the digital athletes of the digital transformation, right? Because I think, when you look at the DevOps engineers and the community, they are the ones who are helping change the companies they work for. I mean, everybody is trying to become a digital business. They are the heroes—I mean, I use the Nike analogy of just get it done, just get IT done. And who does that? It’s the DevOps community.

    And so, what happens is, it’s the ops, to me, is the constraints enterprises have, which is, I want to go fast, everybody talks about going fast and speed, but you need a direction. But you have the constraints of, you need to still be reliable. SRE is a big aspect. So, I want to shift left. So, you want to be compliant, you want to have quality. So, you can’t just go fast.

    So, the challenges with what DevOps engineers are trying to do is, how do I go fast, but still have the reliability, the quality, the security, and still transform the companies they’re trying to do and remove the constraints for the business to go faster in an ever changing world? To me, that’s what we provide with this platform is really to help them make much more productive and make sure that we remove the constraints. They can—even if they are working for a large enterprise, they can still have the benefits of being a born in the cloud company and not have the constraints.

    That, to me, is one of the fundamental things. And they are the digital athletes of the world. And so, to me, that’s really what we are here for, to support the chief digital officers to everybody who is transforming, but the DevOps engineers of the community is who are making this happen.

    Shimel: Fair.

    Langone: That’s a great point, Ashok. And I think, Alan, to just add a little emphasis—you know, what we’re trying to build is a platform that provides functionality that’s complementary to the activity that’s already going on today, right? So, you had mentioned it earlier that, you know, as you’re making these changes inside an organization, a lot of it is sort of people changing their day to day routines, right? So, you know, being more agile, following new processes and things like that.

    What our goal is, is to provide functionality that a lot of the change has abstracted from the user, right? So, in other words, DevOps engineers continue to use the same tools that they were using months ago and weeks ago in the same way, but they plug into a process that’s largely abstracted from them, but gets all the benefits that—delivers all the benefits that an enterprise needs, right? So, to try to make the change and the transition that’s required to really embrace DevOps as, you know, as lightweight and as little impact on people’s days as possible.

    So, that’s really the goal, is to provide functionality that has not existed before, and do it in a way that doesn’t have to require changes of behavior.

    Shimel: Fair enough. Ashok Reddy, CEO of CollabNet VersionOne Xebia, until we find a different name; Derek Langone, president of the entity as well—thank you for joining us, both, today on DevOps Chat.

    We’re gonna—you know what, we’re gonna be watching. This is a great story, it’ll be interesting to see how it progresses, right, both in terms of mergers and acquisitions activity as well as in terms of just—hey, man, this end to end, as I wrote about last week, this end to end DevOps market is open for the taking. There is no one, I think, who really has that whole story yet. It’s a developing thing, and it’ll be interesting to see, you know, how the market in our community helps pick the winners here as well as what you guys do with it, right? It’s yours for the taking.

    Best of luck to both of you and to the combined company.

    Reddy: Thank you, Alan.

    Langone: Thank you. Good to talk to you.

    Shimel: Great talking to both of you. This is Alan Shimel for devopsy.kinsta.cloud. Thanks for joining us on this DevOps Special Edition Video Chat. Stay tuned, and we’ll see you soon.

    — Alan Shimel

  • IBM Doubles Down on Cloud, But Is Krishna an Interim CEO?

    IBM Doubles Down on Cloud, But Is Krishna an Interim CEO?

    Big news from Big Blue yesterday: IBM CEO Ginni Rometty is stepping down after eight years at the helm. In her stead, IBM is doubling down on the cloud by appointing Arvind Krishna as CEO and member of the board. The real move to watch, though, is the appointment of Jim Whitehurst, Red Hat CEO, as president of IBM and a board member. It’s the first time that someone has held the title of president singularly, and it may portend where the real power will be at Big Blue (and Red).

    Krishna was previously head of the cloud and cognitive software division at IBM. He is an IBM veteran, having been with the company since 1990. His appointment sends a strong signal about how important the cloud is to IBM’s future. In some ways, it is similar to Satya Nadella’s appointment at Microsoft. But perhaps it’s not as strong a signal about the importance of the cloud than the $33 billion IBM spent acquiring Red Hat.

    It is that $33 billion investment and the importance of Red Hat to the new IBM that leads me to believe Krishna may, in fact, be a transitional CEO. The eventual appointment of Whitehurst as CEO and the rise of Red Hat leadership within IBM may in some ways be a reverse-merger type of thing, with Red Hat eventually running the show.

    IBM is a huge beast. A company of Red Hat’s size will find it difficult to change the culture and overcome the inertia at IBM. But frankly, IBM has been transitioning for almost all of Ginni’s time there. While the Enterprise Systems group (Z systems mainframe) is still the cash cow, bringing in a large percentage of revenue, IBM has increasingly tried to be a major cloud player.

    The SoftLayer acquisition didn’t quite give the company what it needed, as it was not a public cloud play. It left IBM unable to compete with Google, Microsoft Azure and AWS in true cloud services. After a few fits and starts, IBM decided that Red Hat, with its open source pedigree and cloud strength in both public and private cloud settings, could be the engine that could as it pertains to cloud.

    The street has not been kind to IBM over the last few years as a result of the botched cloud play, either. At a time when its tech competitors and the market in general have soared, IBM has actually fallen, as has its revenue.

    Mitchell Ashley, founder and managing analyst at Accelerated Strategies Group, agrees with this assessment. “We are seeing a sea change in big tech CEO strategy. Like Microsoft’s elevation of cloud exec Satya Nadella to CEO, IBM is rebuilding its executive ranks from the open source cloud software world with the appointment of Red Hat’s Jim Whitehurst as president and board member,” he said. “How soon the Krishna regime including old-line IBM executives gives way to Whitehurst and other Red Hat executives remains to be seen.”

    IBM CEO Change Elevates Open Source from Digital Anarchist on Vimeo.

    Ashley was not the only analyst to weigh in.

    “IBM bet the farm on cloud with the $34 billion Red Hat acquisition,” said Steve Duplessie, founder and senior analyst at Enterprise Strategy Group (ESG). “It was only a matter of time for the succession. Now the two top dogs running IBM are cloud purists. The old IBM died a while ago and they had to change—I like the move! Their stock lost 26% while the S&P rose over 150%. This lets them remake themselves before it’s too late.”

    Changes at the top don’t always portend success. There is a lot of hard work ahead at IBM as the company continues this journey. Competing with AWS, Google, Microsoft and other players in the cloud space is going to be challenging, given the head starts these players have already. But you really can’t count out IBM, ever.

    One other thing I wanted to mention: With IBM’s appointment of Krishna at IBM, there now are CEOs of Indian descent at Alphabet (Google), Microsoft and IBM. This is very positive for all persons of not only Indian heritage but for all people of color and nationalities. Kudos to these companies and these men for their success. Now, how about some women of color in these roles?

    — Alan Shimel