Category: DevOps Chats

  • DevOps Chat: JFrog Announces $165 Million Funding Round

    DevOps Chat: JFrog Announces $165 Million Funding Round

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

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

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

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

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

    Audio

    Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: I think maybe even before five years.

    Ben Haim: I agree with you, yeah.

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

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

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

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

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

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

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

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

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

    Shimel: Yeah, my pleasure.

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

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

    — Alan Shimel

  • DevOps Chat: JFrog Expands Platform with Trainologic Acquisition

    DevOps Chat: JFrog Expands Platform with Trainologic Acquisition

    It’s always great to see companies in the DevOps space grow and expand their breadth of services. JFrog is the latest to fit that description. The company last week announced its acquisition of Trainologic, a Dev and DevOps technology consulting company, to expand its reach by helping new customers start their DevOps journey and supporting existing customers along the way.

    In this DevOps Chat, we speak with JFrog CEO and co-founder Shlomi Ben Haim and Gal Marda, founder and CEO of Trainologic, about the acquisition and how Trainologic fits into the JFrog vision of end-to-end continuous updates.

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

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Today’s DevOps Chat is around some big news coming out of our friends at JFrog, and I’m happy to be joined by my friend, Shlomi Ben Haim, CEO and co-founder of JFrog. Shlomi, welcome.

    Shlomi Ben Haim: Hey, Alan. Thank you for having us.

    Shimel: Thank you. And joining Shlomi is a new member of the JFrog family, Gal Marda, who is the, I guess, founder and CEO of—or was the founder and CEO of Trainologic, correct?

    Gal Marda: Correct. Great to be here. Thanks, Alan.

    Shimel: Welcome, and welcome to the JFrog family.

    Marda: Thanks a lot. It’s very exciting for me.

    Shimel: So, I’m gonna let—Gal, I’m gonna let you tell our audience the big news coming out today. What went down here?

    Marda: So, what went down, as Alan said, it’s very exciting, actually. Shlomi had this great idea of JFrog coming out with this platform, the EPlus platform, which is a complete revolution in the DevOps industry, in my opinion, and he thought that DevOps and the vision of liquid software, to make it successful, it’s both tools and practices. And taking out this platform and making sure it’s successful requires some consulting services as well to make sure that JFrog customers are making the right decision on the way they used the Enterprise platform.

    So, the idea was to join forces together and bring us on to make sure the customers are being successful with the use of the Enterprise Plus platform.

    Shimel: Excellent. So, Shlomi, let me ask you—JFrog as a company has had tremendous success, tremendous growth. Last year, you moved, really, to a platform type of solution in the marketplace, right, offering the platform. Why Trainologic, why now?

    Ben Haim: That’s a great question, Alan. So, as you know, and we spoke about it in the past, the real pain that DevOps is here to solve is not about the milestones of continuous integration and continuous deployment and continuous delivery and continuous testing. These are all very important milestones that created and ________ revolution.

    But, basically, if we will all have a solution that helps us to get to a place that we have continuous updates, that software is being released fast and secure, then the DevOps evolution would be at the procurement level. What we released this year, the Enterprise Plus, is a bundle of seven different products, and it’s not any more one product that you install and run at the server side, then serve your developers. It’s more than that. It’s an end to end binary solution.

    And what we figured out is that we need some experts to help us with the adoption and the know-how and the knowledge transfer among our users. So, we have 4,500 Enterprise customers today. We need Gal’s team to work with us in the field, on customer sites to support that goal.

    Shimel: I wholeheartedly agree, Shlomi. You know, I’m reminded of, back in my days at Interliant, where we did early cloud hosting—things like Lotus Notes and PeopleSoft and Oracle applications. And what we discovered then was, you can never take a sophisticated application like that out of a box, plug it in, and say it’s gonna work, right? There was always, at best, 75 percent, it worked. You always needed professional services, 25 percent, to come in, customize it, fine-tune it, make it work.

    And, really, that—you know, even in the security space, so many of the most successful security companies, when you look at their revenue breakdown, it was the professional services, because security is hard. And people just can’t do it, and so, to me, anyway, there’s no surprise that this is a DevOps problem as well is that you still need those experts to come in and do it.

    My question to you is, though, is that, as a CEO in your position, you’re always—you’re gonna need to balance how many bodies do I want, right? How do we scale this? Because it’s a body intensive, it’s a people intensive business model.

    And so, you know, what—and Gal, you may have experience, having led the charge at Trainologic. What do you do there? How do you keep it in check?

    Marda: So, I—Shlomi, are you taking this, or me?

    Shimel: Either of you.

    Ben Haim: Yeah, I’ll speak about the ratio, and Gal, you will speak about the best practices coming from your experience. I think, Alan, you are right. When you come with—it’s not just the technology, it’s not just the new things that are happening in the market. And the DevOps market is booming. You see it from everywhere, from fundraising to technology adoption, new things, innovation, every morning we are waking up to some DevOps news. So, this is a very exciting day for companies like JFrog.

    But what you also see is that a lot of companies are starting to onboard giant organizations, thousands of developers to a new methodology and new tools. Therefore, we have to keep the balance between what we release to the market and how it’s being adopted. Because otherwise, we will overwhelm our users with technology that nobody understands how to use, and they will—you know, the first reaction will be a reflex reaction of just dropping it and have this mantra of what works should be, stay as it is. If we want to keep innovation, if we—sorry, to push innovation—if we want to keep the market momentum, then we also have to support the market with the onboarding. This is one thing.

    The second thing—JFrog is a product company. JFrog is not a service company. But building the product without helping our customers to better use them is meaningless. It’s just like having a great technology with the wrong execution. So, we are looking up to companies in our field that did this stuff two years ago, three years ago, and how the market adopted their platform. And we learned a lot from it, we did the analysis. So, when we reached out to Trainer Logic and asked Gal to join the team to the swamp, basically, the first thing that we looked at is, is this company already installing ________ Factory and Xray and Bitray and the JFrog pool? Second, is it a big enough team? It’s a TS Super Command Unit, so not too big, and if Gal and the team will be able to build a community, not just with the JFrog professional services, but also with the community of professional service companies around us, and to be some kind of a business development within these units around the world to help us spread the JFrog technology.

    Shimel: Excellent. Gal, do you want to add to that?

    Marda: Yeah, sure. So, you asked about scaling, so I think Shlomi has it correctly. We are going to be a relatively lean and mean command force. We’re not gonna be like thousands of people, but we’re, we can scale in several ways. One of them is, as Shlomi mentioned, by partnerships, okay? We tend to create a network of partners and a community that will help us work together. We’re not going to deal with it all by ourselves.

    And, in terms of scaling inside and taking people and training them, that’s something that we’re very used to doing. We are making sure that young people are shadowing, and we’re grooming them, and we’re teaching them a lot more of our practices, and we’re making sure that they see a lot of different architecture and a lot of different customers with different ways of thinking. And with this kind of activity, they become very experienced in a relatively short time because they see a lot of stuff, and if you take talented people, you give them the right mentoring, you let them see a lot of different solutions and approaches, they become very efficient in a relatively short period of time.

    Shimel: Excellent. So, is this, the commando teams going in and stuff, Gal, do you envision them—so, is every job a one-off, or is there a sort of standardized package that you’ll develop for most customers?

    Marda: Well, it’s still in the making, but I am—we are planning to create some packages, because during our experience in last year’s meeting, a lot of different companies and providing them with different services, we realize that there are the same needs that are returning again and again.

    One of them, for example, would be some kind of DevOps analysis, like a gap analysis of where you should be or where you want to be, and what’s your current DevOps state? So, for sure, there will be different types of packages, and inside those packages, of course, a lot of the work will be tailor made because every company is different, and as you know, DevOps is also very culture related and related to many other things in the company. So, for sure, it can’t be the exact same thing that will be provided, but the general framework in the packages will be, different packages will offer off the shelf.

    Shimel: Excellent. So, Shlomi, Gal said the magic word—culture. How does this—you’ve done other acquisitions. You’ve acquired JFrog China, I saw awhile I was in China, I saw them at an event. Some other acquisitions you’ve done over the years. But those were kinda product related companies; this is clearly a service one. How does that—I mean, you have a great culture at JFrog, right? I’ve witnessed it firsthand. It’s admirable. How do you make—

    Ben Haim: Thank you.

    Shimel: – ________ Froggers in the swamp?

    Ben Haim: Well, first of all, thank you, Alan. You know, we acquired four different companies, from Conan with the C++ package manager for DevOps and then CloudMunch, that becomes the JFrog Insight product. And then DMon and now Crenologic, and the one thing, one rule of ________ is the fact that you always, you should always seek for the combination between the strategy and the culture.

    And, the first time that I met Gal, under the idea of the acquisition was at swampUP, in our user conference. So, for me, there is no better place to bring someone and show him JFrog, not just from a technology point of view and a product point of view, but also community relations and also the Frog vibe and the Frog DNA.

    And then, when we started the discussion between us, actually, the two groups that worked hard on this deal were the HR group and the Operations group. And the first thing that we shared with Gal was the JFrog products. So, I think that Gal wouldn’t join JFrog if he would feel that this is not the right fit on the cultural point of view, and the strategy moving forward can be something that will change the world of the Enterprise culture.

    So, the liquid software vision, together with the JFrog culture, I think kind of blended into what Gal believed in and what his team already is doing for the past 10 years. And what we have seen there was an identical picture of JFrog. It was almost like a glove to a hand, and now, after we signed and they are part of JFrog, I can say that this was a love story from the first moment we met.

    Shimel: Alright, and it was a happy ending. [Laughter] So, I have to ask you, Shlomi—so, now, you’ve acquired a services company, Commandos, what’s next? What’s next at JFrog?

    Ben Haim: That’s a perfect question. Actually, you sound like my ________ now. [Laughter] So, on the service level, I think that what Gal and Tali, our VP of Worldwide Sales, are working on now is how to merge these capabilities now with the Enterprise class, the JFrog class from adoption. This is one thing.

    The second thing for JFrog is the extension of our technology. We see the consolidation in the DevOps market happening. There is two buckets that consolidate all the technology. One of them is the code repository, so you see what happened with GitHub and Bitbucket and so on. And the other one is the artifact repository. So, those two buckets are kind of consolidating all the technologies into it, and we are looking at it and we are looking at the landscape, and with the universal solution we provide and with the hybrid solution we provide and with the freedom of choice philosophy to be a developers first and DevOps first company, we will extend the technology.

    So, stay tuned. I promise you that, at the beginning of 2019, we will have more news about technologies that support our goal.

    Shimel: Fantastic. Gal, I’m gonna give you the last word.

    Marda: Okay. Thanks for that, first. I must relate to what Shlomi said about love at first sight and the culture. It was amazing to see. When Shlomi called me, first of all, I was very flattered and surprised. But what I’ve realized very fast is that it’s kind of where we’re seeing the same thing but we were trying to help our customers in different ways. JFrog was doing that with creating great technology, and we were doing that with providing them with the best services we could.

    But we tried to reach the exact same goal, the exact same way—developer first, technology first, and while we appreciate and we are all people persons and see the people and try to say, to maintain a very special culture. So, I think that’s a great fit in that matter, and I think it’s the most important one. So, I totally thank Shlomi for this opportunity to be part of JFrog, and I feel that we’re very much alike to begin with, but it’s a great honor to join a company like JFrog.

    Shimel: Well, congratulations.

    Ben Haim: Alan Shimel? Alan?

    Shimel: Yes, Shlomi?

    Ben Haim: You saw JFrog growing, and I’m very—you know, I’m very excited to have this conversation with you, because it’s like seeing different generations in JFrog. We will make the world of software liquid. We will liquefy software. This is our vision, so stay with us, I promise you we will have more news for you.

    Shimel: I’m not going anywhere, and I have every confidence in you.

    Ben Haim: [Laughter]

    Shimel: Gal, to you, as they say in Boca Raton, Mazel Tov.

    Marda: To dava. [Laughter]

    Shimel: [Laughter] Alright. Shlomi Ben Haim, Gal Marda, JFrog—congratulations, good luck. We’ll check in early in 2019. This is Alan Shimel for devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Container Security and More with StackRox’s Ali Golshan

    DevOps Chat: Container Security and More with StackRox’s Ali Golshan

    Security has many faces, which is why it’s so difficult to implement effectively. Each environment is different; each security solution is different; the needs of each organization is different. That’s why, as Ali Golshan, StackRox founder and CEO Ali Golshan put it, security has gotten a bad rap.

    Golshan and his company are approaching security from a more DevOps-focused view, providing the necessary tools to enable DevOps teams to include security throughout the entire process. In this DevOps Chat, he and I discuss the many facets of DevSecOps, container security and more.

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

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat. Today’s chat is a little DevOps, a little security, a little containers, little bit of everything. Happy to be joined by StackRox founder and CEO, Ali Golshan. Ali, welcome.

    Ali Golshan: Thanks for having me.

    Shimel: And, Ali, I think I mispronounced your name. It’s “Golshan.” Correct?

    Golshan: Correct. Yes, thank you.

    Shimel: Cool. I try to do it right. So, Ali, let’s start with the obvious, though, maybe some people out here have not yet heard of StackRox, so, before we dive in, just a quick sorta elevator pitch so they have some context.

    Golshan: Sure. We started StackRox three-and-a-half years ago. The premise for the company was we saw a couple of major shifts in the industry. One happened to be the introduction of containerization and microservices, which is a sub-effect of this larger trend that we’ve been seeing, which is application security and development becoming full product life cycle, so ensuring that you can cover security and compliance and requirements from build to deployment to runtime. And containers provided, really, a great packaging and a construct for building applications and microservices.

    And then the second part of it is is that, when you look at this model, we realize that there’s really three fundamental things that are disrupting a $30-billion security industry. This is the whole notion of a full product life cycle needing to be automated. It’s immutability and ephemerality. And, because you can’t forklift traditional security solutions and deal with these three constructs, we decided to go after solving this much bigger problem for what we like to see is for the future of cloud.

    And where we started was containerization just as the fundamental building blocks. As time and market has progressed, we’ve progressed with it, which is focus more on things like APIs and orchestrators and managed cloud environments, but very much with kind of a host-application-centric view of the world. We’re not a network-based tool. We’re not a log-ingest based tool. We tend to focus a little bit more on security automation, detection, and creating a multifaceted risk view of your environment, specific to containers and microservices.

    Shimel: Got it. So, you know, there’s a lot in there and we’ll come back to StackRox maybe a little later in our chat today, but I wanted to – let me hit on a couple of things you mentioned. So the first thing is this whole idea of cloud-native, container-native. You know, when we first saw the shift to the cloud, the security industry’s response was what some analysts called “cloud-washing” existing security solutions. So they took their existing security solutions and they said, “Okay, now it could run in the cloud too. It’s a cloud security solution,” but it really wasn’t. It was a on-prem security solution moved to the cloud. It wasn’t cloud-native and it really was a little bit of a round peg in a square hole.

    I think we’re seeing the same thing when we talk about security solutions built or trying to provide security for containerized applications. Right? What’s involved? Can you – you know, I don’t wanna coin the phrase, but can you “container-wash” an existing security solution and make it a container security solution, Ali, or do you really need sort of container-native-designed security?

    Golshan: To your point regarding traditional cloud environments, I think that was a smaller chasm, where security companies had to cross, because that original movement was a little bit more about virtualizing your environment. So there was still some kind of applicability of running things like WAS or endpoint solutions, to be able to broaden your security posture to the cloud. Obviously, the fundamental problems we saw were created were around how do you automate and provision workloads and then the nature of those workloads remaining. Those were kind of – the new capabilities in the cloud were actually the pieces that created gaps for security.

    So, if you then think about that and expand that further, the capabilities and designs for containers are even kind of another order of magnitude different than traditional. It’s not just virtualization and then outsize your boundaries. It’s virtualization; it’s microservices, every function broken down into a particular service; controlling it end to end. So, if you think about that there’s a large portion of the security industry that doesn’t even look at some of the most critical components of this process, which is the build and deployment. Building constant context there. Building declarative policies from that environment and then using it further. So I think that’s one of the major reasons we don’t see the applicability of traditional security solutions, even more so in containerized environments.

    Shimel: Yep. I mean, Ali, I agree with you and I think that’s why, frankly, a lot of what is today passing for container security seems to be people doing vulnerability scans of containers or, as I think I had spoken to you about the last time we chatted, you know, network IDS for the container. It just doesn’t – it seems very much square peg, round hole. And I’m not saying you don’t need vulnerability management, whether you’re in a container or not, and I’m not saying you don’t need intrusion detection, whether you’re in a containerized environment or not. But to say that that is, quote unquote, a “container security solution” seems just pushing it and just trying really hard to sell.

    But wanted to come back to another thing you mentioned in your opening remarks. And that was around this whole idea of not only are we living in a containerized age, but we’ve seen the rise – and I don’t wanna say the dominance of – but, you know, the whole CI/CD software factory pipeline model of which DevOps is an integral part of and we talk about shifting security left into the software development life cycle. And this is yet another way that traditional security has to give way to how things are done today, so how does that influence or how does that play itself out, in terms of StackRox?

    Golshan: The way we think about that is, if you think about who were the first companies who moved towards containerization and microservices, they were all companies that needed to deal with massive scale, building velocity in their development and to the offerings they have for their customers. And, as a result, they realized that kind of traditional model of building and deploying and managing was just not sustainable because it wouldn’t scale with the human element. So this notion of DevOps, and even containerization as a result, were really tools and methods for companies to be able to increase their level of automation and sophistication as to how they managed and run their infrastructure.

    So the way we look at this is is that, also, it’s the same reason why a lot of those first movers build their own security models around this environment ’cause nothing like it existed. So we see security kind of mapping to the same model, which is, if you think about it, things used to be a little bit more around a model of batch process, respond, do analytics, take those sorts of options. And, again, the way we look at this is is that what containers have done is break that fundamental workflow. That fundamental workflow isn’t kind of “Build something. Check. Build. Check. Build. Check. And have all these gating factors applied by security.” It’s a lot more fluid now. So, as a result, security has to kind of integrate into that whole workflow.

    And this is one of the big things we talk about, which is is that the reason you can’t take traditional security solutions and apply ’em here, it’s not just the form factor of what they’re applying to, but it’s also the entirely new workflow that’s been created by DevOps and these types of environments that impact how a security tool should run. Because it’s not just tying it to a form factor or choke point. It becomes more of a service mesh – not to borrow the word “service mesh” from kind of the service mesh project, but that’s why it lends itself very well. It’s a number of services integrated across the process and then, as you automate these processes, they become force multipliers for each other. That’s how DevOps works and that’s how security should work as well. You can’t break that workflow model just because your security tool.

    Shimel: Agreed. And you’re using the term “workflow model” and I think that’s a great descriptor of it, but, you know, a lot of goes back – and, again, part and parcel with DevOps – a lot of it goes back to the whole sort of Lean IT, based on Lean manufacturing. Sort of, it really is a factory pipeline kind of workflow model. And, when you think about it, the fact that, all this time, we’ve always kinda just stuck security on at the end, at the end of the packaging, so to speak, and then wondered why it didn’t work so great. It’s kinda obvious when you look at it that way, isn’t it?

    Golshan: No, absolutely. I mean, that’s a interesting analogy, right? If you think about it. If you have kind of a industrial environment and you have manufacturing, if you move from a manual workflows to robotics and automated work flows, the sort of security you apply is gonna be very different – how you look for bugs, how you look at, for example, applications. This is a good analogy because it’s a very indicative kind of model of what the current industry’s going through.

    Shimel: Mm-hmm.

    Golshan: So I’ve become a big believer that you can’t – this is where I think security goes wrong, trying to cover too many things at once. If you have a completely new emerging model, like containers and microservices and DevOps, it’s okay to say that our security or our approach deals just with that particular area. And, as small or as big as it may be, it’s important because it adds credibility that you actually understand what it fundamentally is built from and what it’s doing ’cause, if you say anything other than that – “Well, no, mine can cover network and end points and VMs and containers and Lambda.” – well, that’s just a lot of the reasons why the security industry got the bad rap it did. It’s just things fundamentally work different.

    Shimel: Agreed. Agreed. So, Ali, I think we’ve done a great job here, in the first ten minutes or so, of laying out these sort of macro-factors that are affecting not just the tech or even just the security industry, but the – it’s really affects the whole world because we’re all – every company’s a software company now. And so this really has worldwide bedrock kind of effect.

    But let’s turn back to StackRox, right? Full circle back to the beginning. So how are all of these things manifesting itself in –

    Golshan: Yeah, so the way we look at it is –

    Shimel: – in what became StackRox?

    Golshan: – is have one solution that has two modules to it that interoperate. We have the StackRox module that covers build and deployment and StackRox that covers runtime and production. And the way we look at this entire flow is very basic – on one side of the equation, you get to look at all the static and declarative information and you get to use it to say what things should be able to do, and then, any time you run it, be it in deployment, QA, or production, you get to learn from that application more and more and see what it actually can do.

    So our mission is really bridging what it should do versus what it can do. And the reason, for us, the automation part of it is a big part of it is, you know, as companies mature their overall workflow, they will have additional tools that are gonna be provided by their platform providers, by their cloud providers. As an example, you touched on vuln-scanning. Absolutely everybody should do vuln-scanning, but, more and more, we’re seeing it cloud providers and platform providers provide it, so the key there is not to provide vulnerability; it’s to be able to do vulnerability management.

    And the way we look at vulnerability management, it’s either being able to provide the customer the scanner or ingesting the data from all the scanners and then helping them prioritize it – “Where is this running in production? In production, what services are accessible by this?” So, if you have a low vulnerability that is running in a production environment, in a mission-critical app that is exposed to the Web, it should be valued higher than a high vulnerability that is running in dev in a closed-off EPC that has no access to any other services.

    So context is what helps you prioritize, but it also flows the other way. So, in runtime, if you’re doing detection, it’s important to understand, if an attacker, for example, shelved and broke into a – broke out of a container, grabbed some tokens or credentials, you wanna be able to go back and look at the, for example, the secrets that are being managed through the orchestrator and see where else those particular credentials or secrets are available, where else that deployment has happened.

    So, if you think about it, on the left side, you get a lot of really great insight. On the right side of the process, with the runtime and production side, you can make use of those to build very good boundaries and gating factors, and that naturally reduces your attack surface. So, as you feed this information back to the build and deployment, remove credentials or privileges or tools that are unnecessary, you’re inherently making your infrastructure and applications more secure. And, as a result, we have a much better landing zone for what we apply detection to. We don’t have to detect everything; we know where the weak points or where the gaps are in the system, to focus our detection.

    So that’s kinda how we think about the overall StackRox product. Give the customers, especially the build and deployment and dev teams, the right security, auditability, automation tools on the build and deployment side, and then give the right runtime detection, alerting, response, forensics, and enforcement on the runtime protection side, for security folks.

    Shimel: Excellent. And we’ve got a few minutes left here, Ali. I wanted to – for people who wanna get more information about StackRox, is it stackrox.com? S-T-A-C-K-R-O-X?

    Golshan: It is. Yeah. We have all of our information on our website and we actually offer free risk assessments using one module of our product, where a customer can just grab it and understand much better as to what they’re dealing with when it comes to their container infrastructure.

    Shimel: Okay. Let me come back one other thing to you and, you know, the proverbial “Let’s see your roadmap” slide, but I don’t really want you to show me your roadmap. But what do you think is next, not only for StackRox, but as a result of this macro environment that we’re living in? What’s the next shoe to drop here and how do StackRox sort of – I’m sorry about the noise there – how do StackRox respond?

    Golshan: Sure. I think it’s a couple of things. One is we’re seeing more maturity across this entire stack, so we’re seeing convergence around orchestrators; we’re seeing kind of the standards around runtime engines being built; we’re seeing how public cloud providers are consolidating certain services and making other services much easier to use. Perfect example’s all the efforts around, for example, Kubernetes, between AKS, between EKS and GKE.

    So, when we look at these trends, it shows a couple of different things. One, not only are the containers different, but the entire attack surface is going to look very different, so the way you approach this world is gonna look very different in the future. We’re not gonna make the same mistakes we did with traditional security, which is we’re not gonna make the host overly exposed with a lot of user accounts and credentials and privileges and tools and packages. So we think that that host will obstruct the way and the orchestrator will become kind of a new cloud operating system, with APIs.

    And, as a part of that, you’re gonna end up seeing a lot more complexity, so, as companies get more comfortable running applications as microservices, more containers, better grasp of the orchestrator, they’ll get more comfortable running more complex operations and applications on top of it. Naturally, that comes with maturity. And once you have that, you end up going from kind of what right now is, which is very early stages of this ecosystem, which I would consider to be low entropy, to a very high entropy environment you’re gonna end up seeing.

    As a result of that, the way we see security being built is, one, that’s why it’s very important to focus on automation, integration, and the workflow, but, secondly, we see security having to be built in cloud native as a form-factor-agnostic model, meaning leverage the existing frameworks to – if it’s collecting data, for example, from the system, use, for example, things like the extended Berkeley Packet Filter to use that. If you’re running on Amazon or Google, you can use things like Pub/Sub or Kinesis.

    So it’s building more modular, programmable, and pluggable architectures, versus building a binary that deploys in a container and then you replicate that container against a bunch of hosts. It’s about building a sensory model that can understand different environments and make sense of them, not single agents that unilaterally take action, because, as complexity, heterogeniality grows, naturally, there’s gonna be a lot more gray area, as far as use cases go. And that’s where you run into the old problem of alert fatigue, noise, false positives, and then, eventually, you end up with 50 security solutions.

    Shimel: Excellent. Excellent. Well, Ali, we’re about out of time, but I gotta tell you, man: I love this chat. This was great. I’d love to have you back on the –

    Golshan: Yeah, same here, Alan.

    Shimel: We’ll dive into some more of this stuff. Good stuff. Ali Golshan, cofounder and CEO of StackRox, here on DevOps Chat. This is Alan Shimel. You’ve just listened to another chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: Open Source and DevSecOps with Azi Cohen, WhiteSource

    DevOps Chat: Open Source and DevSecOps with Azi Cohen, WhiteSource

    The security of open source code is one many organizations are grappling with. Add to that the number of times that applications using open source code are updated and the integration issues that come with those updates, and it’s no wonder open source security comes into question.

    WhiteSource thinks it has a solution to the open source code security problem. In this DevOps Chat, we speak with Azi Cohen, head of U.S. operations at WhiteSource, about the issues surrounding the security of open source code and how his company is helping to reduce the problem.

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

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and we’re here for another DevOps Chat. In today’s DevOps Chat, I’m happy to be joined by someone who I’ve had the pleasure of speaking with several times, but not on a podcast, I believe, and it’s Azi Cohen – “Cone” or “Cohen,” depending how you pronounce it. Azi is head of U.S. operations and a co-founder at WhiteSource Security. Azi, welcome to DevOps Chat.

    Azi Cohen: Hi there. Good morning. How are you doing, my friend?

    Shimel: Good. Happy to have you here with us. So, Azi –

    Cohen: Okay, and, by the way, the name of the company is WhiteSource Software.

    Shimel: Oh, okay.

    Cohen: Yeah.

    Shimel: I apologize. WhiteSource Software.

    Cohen: Yes.

    Shimel: You know, and that’s a good bridge, Azi. Before we jump into today’s topic, which is DevSecOps-related, for those who may not be familiar with the company, why don’t you give us a little background?

    Cohen: Sure. Perfect. So WhiteSource Software was initiated by three of us. We are three partners that were actually working in a different company that was acquired, going through an acquisition, by CA Technologies. And, through this process of due diligence, we found ourselves getting questioned about open-source that was included or not included, you know, in our technology. And that was a very cumbersome process. Took a lot of time and effort. So, not surprisingly, after the three of us been acquired and spent some time acquiring companies, we realized, “Hey, there must be better way to do all these things,” and, a few years later, we started WhiteSource.

    The idea was to allow companies that develop intellectual property using open source – and, remember, we’re talking about 2011, 2012; open source was well-known phenomena or the use of open source, but still not very well-adopted by the large enterprises – so the premise was to help software houses or companies that developed their own intellectual property, using open source, to have a better management and control of the inventory, the legal aspect or the compliance side, and, later on, in security.

    So we started the company in Israel. We got some grants from the Israeli government. We developed a solution and, obviously, we started to focus on companies – you know, at startups and technology companies. And we were doing very well for quite a long time. I think that the big change came somewhere like 18 months ago, maybe 24 months, where we started to feel a growing demand from large enterprises – banks and technology companies, consultants, large chains, health companies. So all those started to use open source and started to look also for a solution, and that’s when we realized, “Hey, there’s a big opportunity here.”

    We went out, raised a lot of money from VCs, including from Microsoft, etc. Started the U.S. operation. And, fast-forward today, we have a very large office here, more than 30 people, in North America. I run the U.S. operation. We’re growing 300 percent year over year. Almost more than 500 clients, from multibillion companies to small ones, and it looks, right now, that demand is not going to drop.

    Shimel: Fantastic. You know, as they say here in America, mazel tov.

    Cohen: [Laughs]

    Shimel: It’s an American –

    Cohen: Thank you for that.

    Shimel: – _____ success story, right? And congratulations to you and the team. But, Azi, you know, sometimes – and, like you, I’ve been in business 30 years – sometimes, it’s better to be lucky than smart. It’s good to be both. But you really – WhiteSource Software and your team has been a little bit of a benefactor of being in the right place at the right time. We live in an age where so much of our – well, everything is software and applications, but so much of our applications are built on open source component, primarily, right? A majority of –

    Cohen: Absolutely. That there is a Gartner report that states that something like 40 to 60 percent of the new web applications consist of – is consisted of open source and this is just going to grow. Right? So it’s not going to stop there. And we definitely see that by our biggest clients. We see them starting when they have something like 20 percent of their code being open source, very quickly reaching to 30, 40 and more, right?

    So this is not something that is going to happen, and I think there is a very good reason for that. If you look at large ITs today – banks, etc. – you know, the CIOs are being asked to create more and more innovation. Someone wrote an article about it. Something like that they’re required to generate something like 25 percent of new ideas and new application or, if you want new lines of code, you know, 25 line of code, year over year, but they don’t get 25 percent more people to do it. Right? They just get 2, 3 percent. So reuse instead of build is the most obvious solution, and that’s why we’re not going to see that percentage dropping, but going higher and higher.

    Shimel: Oh, and – but it makes good sense, right? So much – you know, when you look at the average application, so much of it is rinse and repeat, right? Sending an e-mail, firing off an e-mail or registration, opening a window. So many of – there’s no sense reinventing the wheel of these things _____ _____ –

    Cohen: Oh, absolutely.

    Shimel: You know, when you look, there’s so much Java script reused, there’s so many Java components reused. There’s so much of these open source reuse – like you say, it’s only gonna be more and more, as these libraries and repositories get bigger. But that begs the question, Azi, of it doesn’t make us more secure, necessarily. And, as a matter of fact, some may argue it makes us less secure. What’s your position?

    Cohen: Well, it’s a great question. You know, and, obviously, when you have one component being used by millions, it’s just an opportunity for attacker to find a way to hack it, crack it and now they have thousands of companies that may be vulnerable to this one, right? And then, for them, an open door to get into those accounts. So what we actually see is that, with the fact that more and more open source is being used, on one end, we have attacker trying to exploit those open source components and we have seen some cases in the past, right?

    In the same time, the community tries to find more vulnerabilities and fix them as fast as possible, but, if you look at the DevOps guys, this create a huge problem because, think about it, on one hand, they use more and more open source; on the other hand, the community, which is very active, is finding more and more vulnerabilities in those open source and provide fixes, right?

    So now the DevOps guys have more stuff to deal with, a larger inventory to track and check and validate, but, on the other hand, we know that the attacker, that know that these guys will patch those vulnerability very quickly, try to hit them faster and faster. So DevSecOps or DevOps guy have more stuff to do in less time. So the only solution is by automation, right? The only solution is by some control that will let them know what’s good, what’s bad, and provide alerts when something bad is happening or when new vulnerability that is – that they are exposing the inventory is _____ _____.

    Shimel: Yep. Absolutely. And you know what, Azi? This is – what you just described, yes, it’s 100-percent dead on for DevSecOps, but it also describes so much of what we are seeing in software development in general. If the machine, if the factory is gonna run, at the optimum speed, we must automate so much of this, right? Because, otherwise, it just can’t keep up and security is certainly no exception. No exception. _____ –

    Cohen: Absolutely. And another thing here is that you have to detect or try to stop bad things from coming in at the gate and not later, right? Because every step later – so it’s automation but also automation at the front of what’s called shift left, right? As early as possible in the development cycle. And then, at WhiteSource, we do exactly that.

    Shimel: Yep. So this begs the question, though, “Sounds wonderful. Let’s all do it. Why aren’t we more secure? Why aren’t more people doing it? Is it really that easy?”

    Cohen: I think it’s mostly a matter of awareness and perception as well. So, firstly, when I meet with CIO, CISOs, they don’t – in many cases, they don’t understand what level of adoption of open-source they have in their environment. Their perception is that, in many cases, that they use only 10 percent or 15 percent of the code, is open source. The reality is it’s higher.

    So perception of the problem is one thing, and top managers in many places don’t understand that the amount of open source being used right now is larger than what they have, but the other thing is that, you know, the perception is that standard tools, like application security testing tools from IBM or from Checkmarx and from other vendors, right, are solving the problem. You know, since they scan the proprietary code, then most likely scan the open source as well, but that’s not true. That’s not the case.

    And the last thing is that, once more awareness or, if you want, education – the assumption by most managers is that open source behaves like the proprietary code, right? You use a scanner. You test the open source. You find vulnerabilities. Somehow, you either fix them or not, and they’re fixed. It’s a one-off. What they miss is that open source is a living thing. You may have a clear open source component that are using now, which is fine, but then, month later, there could be a vulnerability in it, right? You have to be able to track it later on. It’s not a one-off test and gone.

    A good example is Apache’s Struts No. 2, right? A year ago, the whole world was astonished by this Equifax thing that was created by an attack to Apache Struts. Everyone mostly likely fixed it by today. And guess what? Three days ago, a week ago, a new vulnerability in Apache Struts No. 2, which was fixed, was discovered. And that’s not going to be the last one, right? So open source is a living thing, vulnerabilities are coming and going, and you have to keep track.

    So I believe the top managers – CIOs, sometimes CISOs – are not aware of all those effects that came out there, with more open source, right, that the current tools does not solve it. And, finally, that they need a tool that is designed to track changes in the security of their open source inventory along the time.

    Shimel: Exactly. I mean, you talk about Struts 2, which is sort of the poster child here because of all the press and notoriety that Equifax got. And I saw a presentation by – I forgot what company it was, but what really surprised me, Azi, is, even after we knew it was bad and you had to patch it, you had to upgrade it, the amount of people who were still downloading and using the old version – it dropped off from maybe 80,000 a month to 70,000 a month. Right?

    Cohen: Awareness, right? And, by the way, these numbers are changing, so you may not know, but we just released a tool called “Vulnerability Checker.” It can be downloaded from out website, whitesourcesoftware.com, and, basically, it will check – it will do an automatic check to check, for clients _____ – people that are interested whether their systems are affected by Apache Struts 2, right? So for those that are aware and would like to know whether they have some issues with that right now, they can download it free and check very quickly their system and find whether they are affected or not.

    Shimel: Yeah. But this is also the future of where companies need to be. They need to do this and then they need – you know, Azi, I remember I was selling vulnerability management and patching, oh, maybe 2005. I was talking to one of the CIOs. They had three CIOs at Citibank. This is before it was called “Citi”; it was “Citibank.” They had three global CIOs. I showed them a system that would scan for vulnerabilities and, if there was a known patch for the vulnerability, it’d integrate it with a patch manager that would automatically – that would patch these up.

    Cohen: Sure.

    Shimel: And he said, “This is great, but, Alan, we don’t just install a patch ’cause we found a vulnerability. Before we can install a patch, we have to do regression testing on all of the applications. We run about three months behind.” So, literally, there was a three-month cycle by the time they would patch a known vulnerability that they found. And, yeah, I’m not saying it’s that bad today, but that sort of mentality, that approach, just doesn’t work at the speed of business today.

    Cohen: You’re 100 percent right. And I bet that Citi today have hundred times more vulnerabilities per application than they used to have at those days, but this is an important point because we face that any of our large clients – and, actually, we just came up with a very, very smart solution for that. So we know, as you mentioned, that it takes them a long time to patch, right? And we know that they have thousands of vulnerabilities sometimes, and they need to know where to put their time, right? Especially if it takes longer time.

    So we came up with a tool called “Effective Usage Analysis,” and the idea is very simple. When a developer picks up a new open source component, this component usually come with 10 or 15 different functions. Each one of them may have some vulnerabilities, etc., so this entire package could come with, let’s say, 10 different vulnerabilities. But the developers will use only one or two functions, and, therefore, you’ll be exposed only to two or three out of those 10 vulnerabilities. So Effective Usage Analysis is a new module that we release. It runs over the code and identify how the developers use the open source and, therefore, clean out all the non-relevant code.

    So, for this kind of – for the Citis of the world, that have thousands of vulnerabilities, Effective Usage Analysis will drop the number of relevant vulnerabilities by 70 percent – seven-zero. These are the statistics. And now they’ll have only the most severe 30 percent where they can and should spend those three months in order to fix them, on the road to get a better security solution. It’s huge. This difference is huge. We get a lot of good feedback from clients that are testing that. It really helps them to make sure that every hour that they spend is much more effective.

    Shimel: Excellent. And this thing you can also get at WhiteSource Software?

    Cohen: Absolutely. Yeah. It’s a new model that we just released.

    Shimel: And what’s the name of it again?

    Cohen: Effective Usage Analysis.

    Shimel: Effective –

    Cohen: EUA.

    Shimel: – Usage Analysis. EUA.

    Cohen: Yep. Yeah.

    Shimel: Got it. Well, Azi, as I mentioned to you before we started recording, the 15 minutes here goes very fast.

    Cohen: [Laughs]

    Shimel: We’re already over 15 minutes. We could probably talk all day about this, but we’re gonna have to call an end to this episode of DevOps Chat. But maybe we’ll have you back on soon and we can continue the conversation.

    Cohen: Sure. Thank you. It’s always a pleasure talking with you, Alan, so I’m looking forward to it.

    Shimel: No, it’s my pleasure, Azi. I feel like we could sit and talk and go all day about this, but we’ll call it a wrap. Azi Cohen, a co-founder and chief of U.S. operations for WhiteSource Software, thanks for being our guest on this episode of DevOps Chat.

    Cohen: Thank you for the opportunity, Alan. Always a pleasure.

    Shimel: Pleasure. This is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard. You’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: ‘Day 2 DevOps’ with IBM’s Eric Minick

    DevOps Chat: ‘Day 2 DevOps’ with IBM’s Eric Minick

    Now that the concept of DevOps has been around for a few years and more organizations have embraced it, the natural question for many is, “What now?”—especially considering DevOps success is measured by different yardsticks. IBM’s Eric Minick is has been grappling with the concept of “Day 2 DevOps”—enterprisewide rollouts, multiple toolchains, etc.—and the  best way to get organizations from point A to point  B.

    In this DevOps Chat, we discuss Day 2 DevOps and what IBM is doing in the tool space to help organizations move forward, as well as what other projects Eric and his group are working on.

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

    ​Alan Shimel: ​Hey everyone, it’s Alan Shimel devopsy.kinsta.cloud and you’re listening to another DevOps chat. This episode of DevOps chat features a friend of devopsy.kinsta.cloud, frequent contributor, author, podcast guest – none other than Eric Minick of IBM and UrbanCode. Eric, welcome to DevOps chat.

    Eric Minick: ​Hey, it’s good to be with you Alan as always.

    Shimel: ​Fantastic. So, Eric, you’ve been with UrbanCode since like about 2008 but your role has changed a little bit. What exactly is kind of the title role these days?

    Minick: ​​Yeah, I’m looking after product management responsibility across the UrbanCode portfolio as well as rational testing. So have just a wonderful team and boy we’re doing some good things, so having fun.

    Shimel: ​Very cool. So Eric we only have 15, 20 minutes here – I wanted to jump right into a couple of topics I want to talk. The first thing that I wanted to bring up was this concept of like a Day 2 DevOps as you call it or DevOps Day 2. Let’s explore that. First let’s tell our audience what do you mean by that?

    Minick: ​I think, you know, we look at how things were a couple years ago and there were a lot of organizations running their DevOps pilots, trying to figure out, “Is this going to work for us?” and all that sort of stuff. But I think we know it works, don’t we, by this point?

    Shimel: Well, I hope so but we’ll just keep publishing on it until everyone finally agrees, but yes, you’re right.

    Minick: ​So I think people are looking at like, “All right, I’ve got little pockets of DevOps here, some DevOps teams over there. How am I going to roll this out across my enterprise? I think we’ve got good stuff here, how are we going to do it at scale?” So there’s some scalability challenges, there’s also, you know in organization that had some really good ground-up work – like you have a couple of different teams who built stuff ground up and then they look across the way and they’re using totally different toolchains.

    ​And then you’ve got some poor guy who’s been dubbed the VP of DevOps and is being asking, “Well, how’s the DevOps going?” And so it kind of makes sense out of teams that are on different toolchains and try to pull data out of that, get new teams onto maybe one or both or some other toolchain. And so the scaling and trying to reconcile across all these different tools seems to be the challenge of the hour.

    Shimel: Yeah, I do agree. You know Eric it’s funny you mentioned this whole thing like “Can we agree it works?” and what have you because you, like me, we probably live in a little bit of a DevOps bubble where we’re not really talking to companies who either haven’t already started their DevOps journey or are contemplating starting their DevOps journey. But there are people outside of our bubble, right?

    Minick: ​There are. I think I saw one of the analysts who just said, “Yeah, but it’s,” – 40 percent are well on their way through their journey; 40 percent are seriously kicking it off now; and then there’s 20 percent– I spoke to a different analyst who said, “Yeah, I just think that 20 percent is just going to go out of business.” And you saw my article the other day: I agree.

    ​So yeah, if you’re not at least getting ready to start the journey – well, I guess I should just say I’m really worried about you. I was going to say I’m not that worried about you but it’s go time.

    Shimel: Yeah, it is, no doubt about it. So Eric for those folks who are sort of entering day 2 of DevOps – and I think this is a problem, so many people prepare for that D Day assault of day 1 and don’t really have the day 2 plan in place. What words of sage advice do we have for them? Where can they go to get information on this? What can they do?

    Minick: ​So I think it’s really important not to disrupt what’s working. If you’ve got teams that are out on some weird toolchain that’s not the enterprise standard but it’s really, really working: let them run. I think that sort of data has come out – we saw in the Accelerate book by ______ it all that, yeah, you want to empower teams, you want to let them run with good tool chains that are working – the ones that are – hey, this is why I have a very active tools business – this is replacing tools that don’t work with tools that work really well or helping teams that don’t have good automation capabilities around continuous delivery or testing.

    ​But then I think you’ve got to really look at, “How am I going to get a view across what’s going on? How do I normalize some data?” If we know that the key metrics for DevOps are things like lead time from code to production – all right, “How am I going to understand that across a number of tools and normalize that?”

    ​So it’s an area we’ve been doing a lot of work on in the tool space – and some other folks are doing that as well – it’s pretty achievable these days.

    Shimel: Agreed. So I guess when we start talking about issues around – and blueprints and plans for day 2 – the logical next step is, “What about day 3?”

    Minick: ​Well, let’s see what breaks in day 2 first. I don’t know it yet. I guess my dream, right – if day 1 is you have a bunch of DevOps pilot projects and day 2 is you hire a VP of DevOps to spread these new ways of working across your enterprise – day 3 is you don’t need that VP anymore, right – that you’re dedicated – you know, we bring the DevOps group within your organization – isn’t needed because your transformation is complete, you’re an agile technology powerhouse within your business helping the business along – you don’t need that transformation team anymore; this is just the way that you work.

    ​So I’m hoping that’s day 3 – that all these people do transformations and move onto the next big thing.

    Shimel: ​Fair enough. You know I’m hoping so too Eric, though I hope that doesn’t put me out of a job. Anyway –

    Minick: ​​I think we’ve got a decade or two, man.

    Shimel: Yeah, I think I’ve got enough runway. So Eric let’s turn from DevOps day 2 and DevOps day 3 to what’s going on specifically with UrbanCode. You’ve got some new releases out both community and enterprise or commercial editions, so what’s up?

    Minick: ​​Yeah. So UrbanCode Velocities are kind of a brand new star. So we shipped a community edition earlier this yar and then in the last little bit we came out with the full commercial edition. And I mentioned earlier there’s tools that pull together data from different tool chains – yep, that’s where we’re running with Velocity – you know, looking at things like a lot of our customers have anUrbanCode Deploy for a huge chunk of their workload and they’ve got some teams doing something else – oftentimes it’s simpler apps, they’re running it just on a Jenkins pipeline or something – and they want a view across that.

    ​Very often they need to coordinate a delivery across the two where, “Hey, I need to kick this thing to Jenkins and that thing and maybe they could deploy at the same time.” So we want to make sure that you’ve got a common view of what’s in your test environment even if different pieces and parts of your application are being delivered by different tools, and that you’re able to understand things like lead time, cycle time, deployment success rates – kind of the heartbeat pulse/health of your continuous delivery flow.

    ​So really excited about Velocity. It’s in this brand new market space. Some people are calling it Value Stream Management, others are calling it DevOps Tool Chain Orchestration – but it gets into this idea that lots of people are using lots of different tools to get value out the door as part of your organization, and having a view across that and a way to kind of orchestrate across that is really powerful.

    ​So yeah, people are checking it out, they’re loving it – it’s a ton of fun – the funnest time in a product manager’s life is launching that new product, so good times.

    Shimel: Absolutely. So in a way though this kind of goes back to Urbancode’s roots, right, with UrbanCode’s roots in open source and free software, commercial editions and all that – nostalgia Eric in that or lessons learned doing it better?

    Minick: ​​Yeah. I think a little better. We did start out with good old Ant Hill as an open source product – you know, to have a community edition and just say, “Yeah, here’s what you get for free,” which is really a lot of reporting right now for UrbanCode Deploy, “And here’s what you get when you step up,” that feels good and a lot cleaner than the press but – you know, we had tried 15 years ago and we tried to build an open source business.

    Shimel: No doubt about it. Eric, then you have another version of UrbanCode out – was it 7 or something?

    Minick: ​​Yeah, we shipped 7.0 for UrbanCode Deploy – and that’s a big deal for us. You know UrbanCode Deploy started at like 4 so 7 is not – you know, we do big, chunky versions for this – 6 came out a few years ago.

    ​So what got us over to a 7 is some re-architecture under the hood – that’s getting us up from being able to manage in the neighborhood of 10,000 machines on a master cluster of UrbanCode Deploy to being able to deploy to something closer to 100,000. So often 10X is a pretty good improvement.

    Shimel: Not too shabby.

    Minick: ​​Not too shabby. And you know that’s where we’re ______ of the day 2, right? You know, when we were shipping this thing five years ago we asked clients, “Well, what’s the most you’d anticipate ever deploying to?” and they’d say, “I don’t know, a couple thousand machines might be appropriate for this.” But now you walk into a bank and they’ve got 100,000 VMs under management and they want to get to all of it – they want to scale.

    ​And so I guess the two sides of the coin here – so UrbanCode Deploy saying, “Hey, if you’ve got something that works in UrbanCode Deploy and you want it everywhere in your organization we’re going to make sure there aren’t barriers to that,” right? Big emphasis on that.

    ​All right, if you’ve got a little of everything and you want to make sense of that we don’t want to tell you you’ve got to throw it all out and adopt UrbanCode Deploy: we want to bring in something like Velocity and say, “All right. You’ve got a mess. You’ve got 97 instances of Jenkins with 50,000 jobs across them. Let’s bring some order to that chaos. Let’s give you a view across that. Let’s help you orchestrate across that.”

    ​So that’s kind of the two sides to the day 2 coin from our perspective. A bunch of good stuff in Deploy 7 so it’s not just the scalability we redid the UI to make it a little easier to work with, a little cleaner – I think it’s really beautiful.

    ​You know, we made it easier to kind of manage your processes – your automation processes that could easily be shared across a bunch of different applications. It lets you kind of change them in a little sandbox and code review them and then publish them out to all of those applications that share them – we’re calling that a safe edit capability – we’ve added a graphical designer for Terraformdocuments – so you want to describe how you’re going to publish out your workload we’ll do that nicely with Terraform.

    ​So just a ton of great stuff in there. Big emphasis on helping our customers scale really cleanly and then making sure we pick up all those new tech stocks like Terraform.

    Shimel: Got it. Cool stuff. So Eric we continue to see IBM moving forward with UrbanCode and obviously you’ve spoken a lot about a lot of the big developments there within the context of the continuing maturation of DevOps. But you mentioned that you’re also doing or helping to manage some of the testing and – I’m drawing a blank now –

    Minick: ​​Yeah. So testing and service virtualization – so rational test workbench, rational –

    Shimel: Rational. Excuse me. That’s what I was thinking of. I apologize.

    Minick: ​​Yeah.

    Shimel: You know, we only have a minute or two but give us a little update on that.

    Minick: ​​We’ve been doing a lot of good stuff, expanding some integrations for mobile testing. The service virtualization is always really nice particularly – you know, we’ve got a lot of customers trying to modernize their apps – they say, “Okay, I’ve got some big workload. I like to bring it over to Kubernetes, containerize it,” and then you’ve got like the one thing that doesn’t fit in a container – some crummy appliance from a vendor or – maybe it’s your mainframe that’s part of the app – and so service virtualization is really having a good day to say, “Okay, we’re going to stub out, we’re going to virtualize out,” you know this thing that’s holding you back from being able to really leverage cloud or dynamic infrastructure, and then you’re going to – you’ll be able to leverage it into all these lower test environments – we’ll bring that component back in for late testing – and obviously it’s there in production.

    ​So yeah, the test area is really dynamic. A lot of fun. I’m surrounded by a bunch of great people in that area too. So, yeah, it’s a lot of fun.

    ​And I’d say how I look at it is the build/deploy automation you have in something like UrbanCode that’s the skeleton for your continuous delivery – that’s not the path. All the work you do is testing, right? You’re doing performance testing and security testing and functional testing and API testing and unit testing – we could go on for hours – and so these things come together to really be the heartbeat of your continuous delivery.

    Shimel: Cool. Well, Eric it seems like you know you’re certainly busy enough, huh?

    Minick: ​​Not bored.

    Shimel: Absolutely, man. Hey, we’re about out of time here but I wanted to thank you for joining us today and we’ll have you back on soon – we’ll probably be ramping up for IBM Think in San Francisco in a couple months so maybe before then we can catch up.

    Minick: ​​Absolutely. I’m going through session proposals now. I’m super excited.

    Shimel: Cool beans. Eric Minick always a pleasure to have you here on DevOps chat. Thanks for the updates and keep doing what you do, man, it’s great.

    Minick: ​​Cheers Alan.

    Shimel: ​All right. That was Eric Minick, UrbanCode and IBM Rational. And this is Alan Shimel of devopsy.kinsta.cloud. You just listened to another DevOps chat. Have a great day everyone.

    — Alan Shimel

  • DevOps Chat: DevSecOps with ShiftLeft CTO Chetan Conikee

    DevOps Chat: DevSecOps with ShiftLeft CTO Chetan Conikee

    Security in the DevOps process has gotten a lot of attention lately, as companies grapple with ways to include security further up the application development process. The industry is still very much a nascent space, as players remain engaged in the security-versus-speed conversation—one always is sacrificed for the other. ShiftLeft, however, doesn’t believe that’s the case.

    In this DevOps Chat, Chetan Conikee, CTO of ShiftLeft, discusses his company’s approach to DevSecOps and how it can help keep the security department from being the “department of ‘no.’”

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

    Alan Shimel: Hey, everyone it’s Alan Shimel and I’m here for another DevOps Chat – DevSecOps related. I’m joined by Chetan Conikee, a CTO and cofounder of ShiftLeft. Chetan, I hope I didn’t mess your name up too bad.

    Chetan Conikee: Absolutely not, you did a great job. Thank you Alan, appreciate it.

    Shimel: Thank you. So Chetan, as I mentioned you’re the cofounder CTO of ShiftLeft – we’re going to talk a little bit more about ShiftLeft later in the show – but I wanted to start off talking about what is really one of the hottest topics in our world today and that is this whole whether you want to call it DevSecOps or DevOps and Security or Security Shifting Left – hence the name – talk to AppSec, some other people do – you know what about in your world? Are you seeing this kind of emphasis like never before on what some are calling DevSecOps?

    Conikee: Absolutely. Great question, Alan. Let me first start with the term shift left because it has two definite representations; one is a word and the other is a noun. Formerly ShiftLeft started as a way of doing things; meaning taking a practice and moving towards the left in order to reduce what they call as the meantime to repair. And that something could be testing or perhaps measurement of security as well.

    So when we adopted that name or changed the word to a noun we wanted to take this seriously; meaning how can we effectively build a product that can measure the security posture of another product at the left, informed from the right as well because often DevOps is nothing but a pipeline – an affective pipeline that is operating both at automation and high velocity. DevOps is all about taking code, building, packaging and thereafter deploying into your production ecosystem.

    But it doesn’t just end at deploying: it ends at measuring and feeding back how to optimize your systems thereafter. Often security does not fit well into this high velocity motion because most of the security products today are legacy or antiquated. These technologies like static analysis, dynamic analysis or perhaps a web application firewall finds it hard to fit into this streamline DevOps biplane. And I use that term emphasis with heart simply because these tools are producing outcomes and these outcomes are nothing but logs, information, alerts and all of this is sent back to humans in silos. And it is upon the human to figure out how to correlate this information and take affirmative action.

    So in essence this is impeding velocity rather than accelerating velocity, which DevOps is all about acceleration. As a consequence security gets left behind in organizations.

    Shimel: Can I tell you – I’m sorry – that was one of the best ones I’ve ever seen – one of the best definitions I’ve ever heard.

    Conikee: Thank you. Appreciate it. So we take this seriously as well because what we are trying to do is convert that definition into automaton, meaning how can you measure security thereafter quantify threats to vulnerabilities because often vulnerabilities are measures on the left, threats are measured on the right, so how can a human comprehend both these vectors, associate them and then address and fix these issues, because security is a huge concern these days.

    Shimel: Yeah. Agreed. So Chetan this brings up something I wanted to spend some time talking about here today and that is it’s a – not a survey but a study that ShiftLeft’s done – I think you guys had a partner on it – why don’t you share a little bit with our audience kind of just laying the groundwork there.

    Conikee: Absolutely. Today we are announcing the industry’s first real world benchmark of what we call a continuous application security solution. And in order to conduct this benchmark test we partnered and collaborated with Cobalt which is a leading provider of integration testing. They have some of the world’s best penetration testers working for them.

    So in order to conduct this benchmark test we submitted two instances of an application – a vulnerable application. By vulnerable I mean it essentially contains a certain set of vulnerabilities in it which we often test against in order to measure the efficacy of our platform.

    In this test we took that application and we deployed two instances in production. One instance was unpredicted: the typical instance that represents these vulnerabilities and have no protection applied to it. Whereas the other instance was protected by ShiftLeft’s one-time agent.

    So the premise of this test was to essentially let these penetration testers conduct tests against these two applications and thereby come back with results. And both these results had a certain degree of focus. The results were to identify what vulnerabilities can be declared by these pen testers upon the application that is not protected by ShiftLeft and thereafter subject the same set of tests on the application protected by ShiftLeft and come back to let us know whether they could penetrate that application or not, or perhaps could exploit that application or not.

    So this was a 14-day exercise and we defined the scope for this exercise – meaning what we essentially did was identified the most vulnerable or relevant applications called and racked by OWASP top ten and thereafter opened these applications to the Cobalt pen testers.

    Now as they began this exercise and Cobalt had hired essentially three white-hat hacking experts to attack both these applications. Cobalt was able to find and exploit all the six vulnerabilities in the unprotected application which is a validation for the fact that this was a beta application, it had the vulnerabilities and these exercises were successful from the pen tester’s perspective.

    Now they took that same exercise and applied it to the application protected by ShiftLeft and the outcome was they were not able to exploit any of those scoped vulnerabilities that we had described in the application.

    So the proof point for this exercise was to make ensure that ShiftLeft took the onus of protecting the application from any existential breaches or exploits applied by both potential white hats or black hats in the real world.

    Shimel: Got it. So fascinating stuff here. Talk to me now – so how – and forgive me and forgive our audience – we may not be knowledgeable about ShiftLeft – how does ShiftLeft in your company – not as the noun or verb here – how does what you do at ShiftLeft play into this Chetan?

    Conikee: Absolutely. Great question Alan. ShiftLeft is the industy’s first convert solution that seamlessly integrates into DevOps pipeline and protects the application by identifying its attack surface without reacting to threats. And let me explain what I just described in a moment.

    Often security solutions that have been thriving over the past few decades are built to essentially identify and understand exiting threats and thereafter protect the application. And by that I mean often when a threat is applied or an exploit is applied on the application that threat is published in public databases like missed CBEDBs and NBDBs.

    Then after all of these instruments that protect the application are validating every request applied on this application informed of the threat landscape. Now often threats have a lifecycle, meaning an attack or attacks an application by identifying potential breach paths. Now after they attack it is titled as an unknown vulnerability and when it is discovered it becomes a zero day vulnerability and thereafter when it’s published in a database it becomes a known vulnerability.

    Now note that often organizations are exposed in that journey from unknown to zero day known because it’s yet to be published. And for all these instruments that are protecting applications there is yet to update its policies to thereby protect the application.

    So we at ShiftLeft have devised a convert solution that first of all understands the applications evolving at that service. Now in the world of DevOps we deploy application multiple times a day, a week or a month. Now as the application evolves to serve a company’s business needs the application’s attack surface is evolving as well. It’s either heading in a positive drift or a negative drift. Often more times it exists or traverses in the negative side because engineers are coding at high velocity and when they code they don’t take security as a function into consideration.

    As a consequence attackers can figure out more creative ways to exploit the evolving attack surface of the application.

    So ShiftLeft has devised a technique that automatically processes byte code into the CI portion of the CICD of DevOps and extracts what we call is the attack surface of the application. Now from the attack surface we extract a policy: the policy that defines how to protect the application in one time because we do not want to feed these alerts back to humans and ask humans to correlate and address and prioritize these vulnerabilities.

    So in the spirit of respecting the fast motion of DevOps we extract the security profile from this attack surface and bootstrap an agent that is instrumented with the running application.

    Now the job of the agent is to act like one-fold full-time employee. The agent has taken the onus of identifying what is a potential imminent threat that is applied on the application by a black hat hacker and thereby understand better this particular track that’s taking this application into an inadmissible state because often attackers want to first take the application into a state that they wish to take it to and thereafter either exfiltrate data from the application or perhaps install some malicious payload on the host.

    So the job of the agent is to identify and segregate malicious intent and thereafter prevent that particular intent from manifesting.

    Shimel: Now Chetan I sit here listening to you – and keep in mind I have 20 years – 18 years in the ______ site space and I remember writing articles and papers on when is a zero day a zero day, when is it less than a zero day, you know, this whole discussion around what we can do to make our applications less vulnerable.

    And what amazes me is – I think we all agree, right, application security – at least for the last three to five years, maybe more – has really been at the forefront of cybersecurity research and so forth. And it’s only now that we’re starting to see solutions like ShiftLeft which are kind of not the same old same old taking a different view to an old problem or a different solution to an old problem.

    And yet, you know, I just got back from Black Hat – I’m not sure if you were there – we hear about one breach after the next and they’re still spinning money out of ATM machines. Are we finally on the right track to you think? Are we making progress?

    Conikee: Great question Alan. I would say that we have begun to make progress. You know, there is a journey, we have to embark on this journey and that journey means taking a practice and embedding into our typical pipeline – a pipeline of how we build applications, deploy applications and protect applications.

    So this is a beginning but a great beginning. But what has enabled this beginning is inspiration. You know often we learn from other systems and what I’m sensing is security is learning from DevOps. DevOps is all about automation, meaning before Amazon – the advent of Amazon or any public cloud like Azure or GC there was – the notion of provisioning a host took more than one step: we had to write a multitude of scripts in order to provision a simple physical appliance.

    And with the advent of companies like Chef Puppet and the public cloud they created this concept called this cloud formation; meaning how do you provision a virtual appliance in a matter of seconds and make it predictable thereafter? Because there is a system of record of your provisioning script and its evolution thereafter – that is one part. The other part is the predictability: how can you assess that particular script and understand its posture? Posture from a resource consumption perspective and resource provisioning perspective?

    Now if you take these two same principals to the antiquated world of security – and I use the term antiquated because in the past security was all about reacting to threats and alerts and then we had to deal with how to prioritize alerts because alerts can contain mixes of true positives, false negatives, false positives, et cetera. So how can we steal a page from the book of DevOps? How can we automate security? Meaning you’re creating code, from this code how can we automatically extract its security posture?

    Because in the world of security we are assessing code with three particular filters – or what they call SOSAs, sanitizers and syncs – SOSAs are where consumers interact with our application; sanitizers are where we are validating that input; and syncs are all communication points outbound from an application perspective.

    Often attackers are attempting to create new syncs after they successfully exploit the application. So how can we extract this particular fabric or script and thereafter take a security function into consideration?

    So this is our goal at ShiftLeft and we are hoping that this becomes a norm and other companies like us are adopting the same principal as well.

    Shimel: We can hope can’t we? But it’s interesting. You know I – what’s interesting Chetan is no developer raises their hand and says, “I want to develop insecure code.” No ops person says, “Boy, I want us to be the victim of a breach or have a security incident.” Nor does any security person say, “I hate the rest of the IT team so much that I hope they get hacked.” Right? None of this is true.

    But yet we have problems – and some of it granted is not just from a technology or toolset perspective, a lot of it frankly is cultural, right, as I’m sure you’ll agree as well. You know, and any time we could use tools that help foster culture, that help foster greater communication and teamwork – I mean I think we all benefit from it, right?

    And I hear a little bit with ShiftLeft, you know, this is something that I think is a byproduct if you will of your solution, is that true?

    Conikee: Absolutely. Well said, Alan. For the most part security should be an enabler rather than a department of no.

    Shimel: You’ve got it.

    Conikee: And security should – there should be a common lingua franca between various departments: meaning security, engineering, quality assurance and operations should speak the same language. The language should be comprehensible so that it becomes actionable.

    Shimel: Amen. Amen. You know, Chetan when we first started I think I mentioned to you the time goes so darn quickly.

    Conikee: Absolutely.

    Shimel: We’ve blown past our 15 minutes onto 20 here so we may have to call it an end but for people who may be interested in the recent study you did with Cobalt – and my friend Carolyn Long is a VP at Cobalt and she is one of the smartest people I know in security – where can they get more information?

    Conikee: Absolutely. Please visit blog.shifleft.io and on our blog we have a recently trending article that gives you the necessary detail about this exercise. And at the end of the article is the published benchmark’s test for those that want to delve into the detail – which I highly recommend – and thereafter visit www.shiftleft.io and – or contact us; we are happy to onboard your application and thereafter protect your application as well.

    Shimel: Fantastic. Chetan Conikee CTO co-founder ShiftLeft. Thanks for being our guest in this episode of DevOps chat and continued success with ShiftLeft – your success is all of our success.

    Conikee: Thank you Alan. Pleasure, and thank you for hosting us.

    Shimel: Okay. This is Alan Shimel for DevOps Chat. You’ve just listened to another DevOps Chat. Have a great day and see you soon everyone.

    — Alan Shimel

  • DevOps Chat: Cloud-Native Security with Twistlock CEO Ben Bernstein

    DevOps Chat: Cloud-Native Security with Twistlock CEO Ben Bernstein

    The rise of containers and microservices has given rise to a need for a different type of security. Ben Bernstein, CEO of Twistlock, believes cloud-native security is the answer. Fresh off another round of VC funding, Twistlock has big plans to advance cloud-native security in the container space.

    In this DevOps Chat, we talk funding, serverless and cloud-native security with Ben. As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Alan Shimel: Hi everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. I’ve got a really exciting chat guest and subject lined up today. I’m happy to be joined by none other than Ben Bernstein. Ben is the CEO founder of Twistlock. Ben, welcome to DevOps Chat.

    Ben Bernstein: Thank you, Alan. I’m really excited to be here. Thanks for inviting me.

    Shimel: Not as excited as I am to have you here. You know, as we were talking off camera, we’ve done other podcasts with Twistlock, but I don’t think we’ve had the pleasure of having you on. It’s a real pleasure. Ben, we’ve got some big news we’re going to break today. Twistlock has raised – is it a round C?

    Bernstein: Absolutely. Yes, round C.

    Shimel: Tell us a little bit about it.

    Bernstein: We’re really excited about it. It’s a $33 million round, which bring us to about $63 million in total money raised. It’s led by Iconic Capital, which is pretty a unique family office that’s probably the largest family office in the world, headed by some of Silicon Valley’s top entrepreneurs, which is a very – something that really made us happy to see that we got the interest of such an awesome funds. So we’re pretty excited about this, and having them join our board. It’s also kind of unique because we sort of reached a growth stage, which is first for me, as a CEO, it’s kind of an interesting to see how the company evolves – sort of the level of maturity we’re starting to hit, which is just exciting. It’s just like seeing your kids go to college or something, I guess. [laughter]

    Shimel: Well, look, my oldest son is leaving Friday for college. I know how that feels, Ben. So $33 million in this round, about $60-something million in total. As we were talking off-mic, I was telling you my experience with raising money. Raising money is never easy per se. When you have a good product, a good company, and the right space, it gets easier maybe, but it’s never totally easy. So congratulations on a sizable round here. It also coincides with a new release for Twistlock. Is that correct?

    Bernstein: Yes, we actually recently released 2.5, which was a pretty interesting release for us, because it updated some of the – or reinforced our investment in Cloud-Native, which is not just container specific, but also augments our complete suite for Cloud-Native computing. So there were some pretty extensive serverless additions there, AWS Fargate addition there as well as some interesting capabilities around forensics, but overall it was a pretty extensive addition to our suite. So we’re very happy about that as well.

    Shimel: So Ben, you mentioned an interesting thing and that is this concept of the whole Cloud-Native space is exploding. We have the Cloud-Native foundation, and all Cloud-Native tools and so forth. Originally, when I heard Cloud-Native, it was very cloud computing, AWS, Azure, that kind of cloud, but with the advent of containerization and Kuernetes and Docker and so forth, it’s really almost I don’t want to say dominated – or synonymous, but it’s so closely linked. From a security point of view though, Ben, where do you see the overlaps, and then where is the difference from Twistlock’s point of view?

    Bernstein: You mean between specifically serverless and –?

    Shimel: Yeah.

    Bernstein: Yeah, so at the end of the day, I think there are two types of application security companies. There are box companies and there are cloud companies. When you think about cloud, it’s basically – it embeds in it the concept that you don’t own the infrastructure. It embeds in it the fact that the people that get the resources get everything in a box. They get the networking. They get the storage. They get everything with a click, whether it’s a public or a private cloud, and it embeds in it the fact that you’re using microsegmentation. It’s about code reuse. It’s about a lot of good things that we all are sort of learning in the past I’d say 8 to 10 years, unless you’ve been working in Google or some of the companies that probably invented this space in house.

    Everything I just said is not about a very specific technology; it’s about specific concepts. These concepts are very disruptive to the way security is being built, and we at Twistlock, believed initially that _____ be the poster child of how existing security cannot protect containers, but when we’ve seen that, it’s not just about containers. It’s about other technologies that are being used by DevOps teams in modern organizations going through so to speak a digital transformation. We decided that we should really expand what we do to go beyond containers pretty early on, and go to really focus on Cloud-Native, which is a suite of technologies, that even includes VMs, but is all about giving or empowering these groups, DevOps groups, to be able to move fast and still secure their work loads.

    This is something that’s hard for them to do with seven different legacy products, where they’re trying to script their way somehow into putting something on the hardware firewall, plus virtual appliance, plus something that needs to – that has a concept of a server, or was built around a concept of a server, where in reality, it should have protected the app, not the server. But anyway, that’s – and so in this – when you think about it in these terms, serverless and containers, and even VMs, if you use them in a certain manner it’s pretty much similar. If it’s immutative, it’s declarative, it’s predictable, a lot of things that really change even the level of security you could wrap around it.

    Shimel: You know, Ben, I also wanted to make the point that so much of this technology is wrapped around the – it’s intrinsically linked with DevOps and a new way culturally of how companies approach not just application development, but specifically application security. I’m wondering – some Twistlock guys, 2.5 guy, your new version out, how does the whole DevSecOps thing movement manifest itself into real features and functionality that we see in the Twistlock suite?

    Bernstein: So when we created Twistlock, we realized that existing security was sold to say seven different people in the company. You take the storage person and sell him storage security. You take the network person and sell him network security. You take the server person and sell him server security where when in fact, everything you were trying to do is to protect your app. Maybe there were other people who you sold different security solutions. What we’ve seen is these five people are actually one person in the Dev Ops area. It’s one person that does a single click and – or several clicks and gets all these good things, but he’s in charge of that because he gets all these things from a single source – the cloud.

    In our bet, which went beyond just specific technologies, and it is kind of counterintuitive to security in general, we said that security had to actually contain multiple layers of security from the same suite. So there’s no point anymore in getting vulnerability assessment from one vendor and east/west firewalls from a different vendor, and anomaly detection from a third vendor, and _____ from a fourth vendor, obviously unless you have a point in it. Most DevOps team, as long as you could – as long as the product is good, they would be happy to get a suite that allows them to get all of these things from a single source.

    That’s one of the bets that we’re taking. It’s a pretty dangerous bet because security has not been that way so far. Luckily for us, it seems to – it seems to be paying off so far. We have hundreds of customers and are doing pretty well.

    Shimel: To say the least. I think you’re being humble. $33 million dollars more in the bank. The usual thing is you’re going to use it for sales or marketing and engineering and support, but specifically what do you – with this kind of rocket fuel in the tank, what we can we look for from Twistlock?

    Bernstein: Well, to be frank, if – I was at the last DockerCon and I saw that people are actually looking for real cloud-native. There’s a real need. If you look at the language, you see that people understand the need for cloud-native security, and what we really want to create is the – a complete solution that people would love and continue to use. So we need to continue to invest in the product. The product is the key. We don’t know how to play golf with executives. We haven’t been very successful at it generally. We really think that what really shines is a good product and a good support team to actually make sure the customers are happy and are using the product right, and that customers are smart, and that they can evaluate things and buy through the channels that they want to use.

    But we’re going to keep doing that, keep trying to make sure that our product is really the most complete solution possible. It gets challenging over time as customers move more workloads into the cloud. They have more demand. We need to excel at doing that, but we’re going to be very focused on making sure our products are – really excels and from that, we believe that given intelligent customers and a supportive team that supports the customer will continue to succeed. So not a lot of huge news there, but just given the demand and given the sophistication of Fortune100 customers, we need to keep – even keeping a product as is requires you to continue and grow just because of the requirements coming from customers over time. We need to do more than just keep the existing product as is. We need to really grow and support new technologies. So anyway, it’s a complex task and we’ll continue at it.

    Shimel: Absolutely. Congratulations, Ben. Over the years, I’ve had a chance to work with many entrepreneurs, VCs, successful business folks. Any one of them will tell you doing what you’ve done here with Twistlock, regardless of where the end game actually winds up playing out at some point, is really something to be proud of. So congratulations to you and John and the rest of the Twistlock team on both the new version as well as the significant new raise.

    As I mentioned to you off-camera, Ben, the time goes so quick where we’re pretty much right on the edge of our time frame here. Wanted to just quickly end up, for people who maybe aren’t as familiar with Twistlock, want to get a little more information, where could they go?

    Bernstein: We have tons of information on our site, Twistlock.com, about use cases, about customers, about cloud-native in general. I encourage people who’d like to learn more to go there.

    Shimel: Fantastic. Well, Ben Bernstein, CEO and founder of Twistlock, thanks for being this episode’s guest on DevOps Chat. Congratulations on all of the good stuff, all of the good news coming out of Twistlock, and continued success.

    Bernstein: Thank you, Alan, for having me. Thanks everyone for listening.

    Shimel: All right, a pleasure. This is Alan Shimel for devopsy.kinsta.cloud. you just heard another DevOps Chat. See you soon, everyone.

    — Alan Shimel

  • DevOps Chat: The Impact of Automation on DevOps and Society, with Bob Reselman

    DevOps Chat: The Impact of Automation on DevOps and Society, with Bob Reselman

    Those of you who have been reading devopsy.kinsta.cloud for a few years are familiar with the RoelBob cartoons, which have a prominent spot on the home page. RoelBob’s creator, Bob Reselman, is also a technologist and creator of other forms of media. Lately, he’s been writing a series of articles about the impact of automation on society as a whole—not just DevOps.

    Bob is a really smart guy and a great interview, as well. Even if you don’t agree with this thoughts on automation, it’s worth giving what he says a listen.

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

    Alan Shimel: Hey, everyone, it’s Alan Shimel, and you’re listening to another DevOps Chat. Got a really great DevOps Chat for y’all today. I’m joined by a good friend of mine, a frequent contributor, one of the team at devopsy.kinsta.cloud—none other than Bob Reselman, creator of the RoelBob cartoons, Bright Ideas TV, the creative force and brains behind Shimmy Tunes, as well as a writer in his own right, not only at devopsy.kinsta.cloud, but at a lot of the leading tech companies out there today.

    So, Bob—welcome!

    Bob Reselman: Oh, thanks for having me, Alan.

    Shimel: You know, I hope I didn’t embarrass you at the log-on, but you know, you’re something of a Renaissance man, right?

    Reselman: [Laughter] Right.

    Shimel: I was reading a little bit of your life history, your life story, Bob.

    Reselman: Oh, yeah. Well, I came to tech late. I came to tech in my early 30s, and the reason I got into it is because somebody told me that I could actually compose music on a computer.

    Shimel: [Laughter]

    Reselman: No, it sounds funny, but if you’re a composer—and I don’t mean—

    Shimel: Like in the MIDI days. I hear you, dude. I know people like that.

    Reselman: Yeah, back in the MIDI days, and you know, if you had a string quartet or even something larger, like an octet, to actually hear that going on, to hear it was very hard. You had to go out and either hire a quartet to play or just be really good at imagining, or be able to sit at a piano and be able to pay some stuff. And I’m not the world’s best pianist, so this medium, this technology really opened up a world to me.

    And then one day I’m sitting around and I’m starting to play with this, and I’m writing it, you know, my string quartet and stuff. I said, “You know, I think I could probably do something with programming.” And so, I did. I actually, I learned to program, and I’m one of those people that came in through the back door. Eventually, I ended up at Gateway, at that time, Gateway 2000, and I—

    Shimel: [Cross talk] cows, we remember it.

    Reselman: Yeah, the cows, yeah. I moved from Boston, Massachusetts to Sioux City, Iowa, which was a complete cultural transformation for me. But every day, I went into the future, this big, big building where we were making computers. I learned a lot, and we can talk about that, too.

    And at Gateway, I was really doing a lot of stuff I shouldn’t have been doing, but I did ‘em, anyway. And I mean that, I just, I sort of had to battle my way into technology. And they were very supportive, and I just learned a lot about some real, hardcore tech, working for that company, and for that, I’m ever grateful.

    And so, that was around ’98. Around 2000, I decided to move on, and I had started doing Big 6 consulting, went into Big 6 consulting. I went into New York and I worked in the financial industry for a while, and then I got good at it. Along the way, back around 1995, I published my first book about DB programming, and Wygant has been very good to me. I still get those royalty checks every month. I can’t complain. That’s how I got here—that’s how I got here, you know? And here I am today.

    Shimel: So, Bob, over the last couple years—I mean, look, we’ve been doing, so, devopsy.kinsta.cloud has been around four years. You’ve probably been doing writing and RoelBob stuff for, what, three years, two and a half years—something like that?

    Reselman: I think three. We’ve been together for a while, Alan. It’s been, you know, the “Casablanca” of technology, what can I say? We’re on the runway, walking into the fog, right? [Laughter]

    Shimel: [Laughter] Round up the usual suspects.

    Reselman: There are no usual suspects. [Laughter]

    Shimel: But Bob, you know, certainly with the advent of DevOps and a heavy emphasis on automation, but also, it’s not all DevOps, it’s the world we live in, as you’re fond of saying.

    Reselman: Mm-hmm, mm-hmm.

    Shimel: You know, automation and the specter of increased automation over the—you know, not only near term, but long term—is really, it’s a scary thing. It’s scary for me as a parent with teenaged boys in terms of what are they gonna do, but it’s scary for a lot of people, people in the workforce today. And it’s something that you have really given a lot of thought to, you’ve written extensively about it, and that’s what I wanna talk to you about today.

    Reselman: Mm-hmm. Well, I’m happy you do, because I do think it’s important, and I think it’s going to have a growing impact. A lot of people—within technology, we can sort of ________. We’re in the middle of it, and we’re pretty adept at adapting—I don’t know if that’s a real term, but we pick up stuff pretty quickly, and we’re good at getting new stuff onto our fingers very quickly.

    But there’s a whole segment of the culture that has problems with it, to be honest. And, you know, let me be direct. Let me be direct, here. My father, he was a cab driver. He was a cab driver, and when I look at what Uber and Lyft are doing to the cab industry in New York City, it’s pretty amazing. I mean, his first medallion, I think, cost him—I’m making these up, I don’t have the actual data, but I think he paid $250,000.00 for his first medallion. And back then, that was a lot of money. But there were only a set amount of taxicabs on the street, and so, there was a high volume, it was a good investment. Today, because of the ride sharing, share services the value of medallions is dropping dramatically. And that’s just one impact of automation.

    Uber and Lyft could not exist without, I wanna say, two fundamental technologies coming on. First of all, credit cards. The other one is GPS, and the third is cell phones. And you mix all three of those together, and anybody can really be a driver. Why? Because you can pick up qualified customers and bill them without having to worry about being paid. GPS will pretty much tell you where to go, and cell phones provide the mapping technology to get there—all of it highly automated.

    Now, what’s interesting to me is that I wonder about the actual Uber and Lyft drivers now as that automation extends. For example, I take Lyft. I take Lyft all the time, and I’m more of a ride sharer than I am a car owner. And I’m sitting in the back of a car, and I had to go to an appointment, and I started reading a book. And I noticed that we were going in the wrong direction. We were going in the wrong direction. I said to the driver, I said, “You know, we really are going in the wrong direction,” and her response was, “Well, this is where the map is telling me to go.”

    Now, what is relevant here is, how far are we really—what is the purpose of that driver, other than to be an interpreter of map data and to manipulate the technology accordingly? And that’s not that far from robotics, and people—

    Shimel: No, it’s not. And actually, I mean, Bob, Uber and Lyft’s end game is to go autonomous, obviously, right?

    Reselman: Right.

    Shimel: And take the driver out of it altogether. But the interesting thing, I’ve had, specifically around Uber and Lyft, but they’re really poster childs for this, right?

    Reselman: Mm-hmm.

    Shimel: When we start thinking about the future of autonomous vehicles, we start thinking about, what really is—what is the disruption in Uber? You mentioned three key technologies, but is Uber really a technology disruption company, or is Uber a company that, what it disrupted was, by taking advantage of all of the excess vehicles and time that drivers have and putting that to good use? And so, was that the true disruption there, or was it the technology that was the disruption, and part and parcel with that technology is the automation?

    Reselman: Right. I think the disruption—it’s the aggregation of the technology which is the disruptor. Now, what is being disrupted? I think there’s a fundamental social disruption going on. The rules of existing as an employee or a wage earner or a value creator in society is changing. And Uber’s talent in terms of transportation—because it’s everywhere, you see everybody getting into those Uber cars. But that’s really inconsequential compared to the larger impacts of transportation.

    So, for example, container shipping is, Swedes Burkett just released a thorough—and again, people can write me and I’ll give them the exact data, because I don’t have it in front of me—but I believe it’s called the Burkett, and that’s a large container ship that’s completely robotic. So, imagine how much containers get shipped on the open seas that have crews. Now, those crews will go away.

    The same as with trucking. Trucking is really low hanging fruit. There are 3,000,000 truck drivers, and Uber is active in the trucking—automated trucking industry. So, they’re looking to automate that, and that’s gonna have a disruption.

    I wrote—the last article I wrote for you all was called “Coming Apart in the Age of Automation,” and the unintended impact here is that we really are creating a bifurcated society in which one class has, can master the technology or becomes the merit class, and the other class is just sort of hanging on. And it’s a sad thing to say, but it is true. And, as we look around current events, we can see that more and more.

    Now, the good news here is that we’re in a—we are in a good position. And what I mean by that is that, if we go back and we look at the history of technology, particularly around the advent of mass production in consumer technology, which is really the automobile. The automobile really was a game changer, because it was intended to be a consumer product once Henry Ford figured out how to do the assembly part. And because it became a consumer product, it really lifted the whole middle class. It became—if you were coming off a farm in Georgia, you could go to Detroit, and without having to learn a whole lot of new skills, become a wage earner in a factory.

    That’s good. Nobody really understood the impact of the internal combustion engine back in 1900 or 1910, that in 100 years, this would have a significant impact. And what I hope we’ve learned along the way is that technology does have an impact, along with sociological and economic. And we can start planning for that accordingly. Sadly, what I’m not hearing is that planning. People hear—the argument is, technology, yes, will always displace people. There are no more people picking up the horse dung on the streets of New York. Those people went to work in factories, et cetera, et cetera. In other words, technology destroys jobs, but it creates more jobs.

    But we’re not hearing any sort of ancillary planning of what the downside might look like, and if there is a downside—which there might very well be—how we’re going to address that.

    Shimel: Yep. I—you know, Bob, maybe I’m cynical in my old age. [Laughter] I—unfortunately, planning is not our long suit, right? We live in a financial world where we live quarter to quarter, week by week, you know? A bad quarter can cost a CEO their job and lose trillions or billions—not trillions, but billions of dollars of market capitalization.

    Reselman: Mm-hmm.

    Shimel: The fact of the matter is, if you believe the media, most people in our age group, Bob, have not put away enough money for retirement.

    Reselman: Mm-hmm, mm-hmm.

    Shimel: We don’t believe in science or truth, [Laughter] and so we can’t even plan around what to do about climate change. Why should this be any different?

    Reselman: Well, I don’t know if I agree with your assessment completely.

    Shimel: Okay.

    Reselman: Because I just got through reading a book by Harari about, it’s an assessment of current conditions and future. And people forget that famine and people dying of starvation even 50 to 60 years ago was a common day event. A lot of people in China starved to death. That really did happen. People in Ireland, in 1840 when the potato famine came along, they starved to death. You didn’t have enough food, and you died. Death due to starvation is still around, but it’s not commonplace—nowhere near the condition that it used to be.

    The other thing is, when we look at warfare—yes, there are wars going on and there are mutual wars, but there hasn’t been a war on the scale of World War II since World War II. So, there’s stuff going on that sorta gets hidden behind all the—what would we say—the fascination with the bad stuff.

    The other thing to think about in terms of us as technologists is that planning is still part of the industrial fabric. What do I mean by that? It takes five years to design and manufacture a car. I learned this when I worked at Edmonds. Pretty much, if you start looking at model years, the big model changes are in the fifth year. Pretty much, if you came out with a Car A—in year one, you’ll have A, then year two, what used to be options become standard and then more options become standard. And then, by year five, you have enough research in place and enough retooling of factories in place to create a new vehicle and put it on the market itself.

    So, industry does have the ability to plan. I mean, just look—I mean, if we look at SpaceX, bringing that rocket back and just being able to send a rocket up, you know, one of those cylinder rockets, right, that you used to imagine from the ‘50s goes up? And we used to just blow ‘em up and leave them in space. Now, we can actually bring them down and allow that piece of pipe with rocket fuel in it to land safely on land. That’s pretty amazing. You can’t plan that in three months. That takes years and years and years of planning.

    So, we have the ability to plan. The question is, in terms of our social imperatives, and that becomes a real question. So, why—what’s stopping people from saving? Why are people afraid? Why is fear so high now? And then also, going back to jobs as, we’ll call them no-skill jobs, start being eliminated from the landscape because grunt work is always the easiest to replace; thinking work is harder. Then, what do we do about that?

    And there are people out there offering solutions, but they are pretty dramatic, and there’s two, and they’re dramatic, and to even start contemplating that really requires a lot of courage.

    The first one is, is that there’s a good case to be made that we are at the end of the consumer based economy. Again, let’s go back to Ford. You know, an automobile for everybody changed everything. And when you look at it, you know, how many cars can Bill Gates drive? Well, if indeed, he had 365 cars in his garage, he could drive a different one every day. The fact is, he probably doesn’t, and he probably takes an Uber. So, really, in the future, you know, we’re all gonna be sharing cars.

    So, this notion of ________, and I didn’t do a good job explaining it. In other words, what I’m saying is that, for a lot of people, having devices and technology is what makes the economy run. Everybody needs a cell phone. Having mass distribution of cell phones makes the economy run. Having mass distribution of food makes the economy run. Mass distribution, mass distribution, mass distribution.

    Well, at some point now, what’s happening is, we can produce as much as we like. Production is no longer a problem. Two hundred years ago, production was a problem. The factories couldn’t make the stuff fast enough. Now, the factories can. So, now we have infinite production, which means we have infinite consumption, which means we have a problem with too much plastic in the water, and too much carbon monoxide in the air.

    Shimel: Bob, I’m gonna butt in here, if you don’t mind.

    Reselman: Okay.

    Shimel: So, I just got back from China last month.

    Reselman: Okay.

    Shimel: There’s a real problem there, right? Because this is—they’re living it, right? And, you know, we look at the world’s steel market and tariffs and all that stuff, a lot of it is being driven by—China has built over capacity in terms of what they can actually use and even sell at a decent margin in terms of steel.

    Reselman: Mm-hmm.

    Shimel: But not just steel, they are producing solar panels, cellular phones. They just—in other words, they are the kings of this, “Hey, we’ll produce as much as we possibly can produce because we’re gonna, if we’re not gonna consume it, we’re gonna sell it in the world market, and if we can’t make a profit on it, well, we’re not capitalists, anyway, right?”

    But an interesting dichotomy that I saw there was that they still are manually labor intensive in certain things. So, their streets are pretty clean in the cities, and the streets are clean because, on every street, there’s a cadre of people walking around with bamboo poles and palm fronds, kinda thing—literally sweeping the streets. And they sweep it into a pile and then some other person comes by and they have all these uniforms. And it comes by on a machine, like a Zamboni machine excepts it a vacuum, and sucks up what that people sweep.

    Reselman: Mm-hmm.

    Shimel: It’s almost like busy work to me, but what was fascinating to me is that, on one end, I took the bullet train from Shanghai to Beijing, right, and 300 and something kilometers an hour. And all I could see out the window, Bob, were endless cranes and towers going up, right? Not just a building, but cities and towns being built one after the next, and all built around factories. They’re like old factory towns, they kinda looked like, right?

    Reselman: Mm-hmm, mm-hmm.

    Shimel: So, they got the infinite capacity to build things, but I really question the infinite capacity to pay for things, to consume these things.

    Reselman: Right. Well, you hit it on the head. It’s the notion of payment. That’s sort of like, it’s like an assumption that we might have to start questioning, which leads into the second point that I was gonna bring up. You read my mind, Alan—and do my a favor, when you’re reading my mind, please clean up after yourself.

    Shimel: [Laughter] Okay.

    Reselman: Right, so the first point is, we have to start examining the role of consumption as a driver of an economy. We just gotta start looking at that. That’s a big question with incredible ramifications.

    The second one becomes this notion of paying for stuff in order to get what you want. And to—let me share a real life funny. My wife has decided that she needs—she wants to get rid of a chair we never use. It’s a nice leather chair that we never, ever use, and we paid, I think, $600—whatever it was, it was too much. I’m not a decorator, but she paid it, and now she’s saying, “I wanna sell it for $200.”

    And so, she puts the ad out on Craigslist and nobody’s biting, nobody’s biting. Why isn’t anybody biting? Because my suspicion is, it’s a good price for a $600 chair, but they can get ‘em for free. They can get probably an equal chair for free. And, if you look at the cell phone, I mean, we’re giving away cell phones. We’re giving it all away, we really are.

    And so, this notion of, what you’re saying is, how are people gonna pay for it? Probably they’re not. Either one of two things are gonna happen. Either the buildings are gonna be left unoccupied and it’s gonna be, there’s a downward recession—or the alternative is to blast credit into the economy to create money and to have that money become a purchasing agent. Is there wealth created? Is there value created? I don’t know about that. I don’t know about that. But are there transactions created? Yes.

    So, I’m being long-winded by saying that it might be coming time to start looking at a serious examination of universal basic income. And let’s just sprinkle the fairy dust for a moment, and let’s sprinkle the fairy dust and say that we’ve just—everything is great, everybody’s just calmed down. They understand that automation is great and if we let machines have their way, the machines can do just about everything now. And every week, you know, you get a check in the mail that allows you to go down to the grocery store or, better yet, interact with Amazon Prime, and the drone shows up with your food. And you go to your TV set and there’s your streaming TV. And some people decide they wanna be philosophers ________, so there are brain surgeons, and other people just decide they wanna sit around and play video games all day.

    There’s our future, right? Is that so bad? Is that so bad? And people say, “Well, how will we innovate? How will we go forward?” And my question—and I don’t have an answer for this—is, I wonder if somebody who gets into something like brain surgery for the money or curing disease for the money? Maybe the recognition, we don’t know. But the notion of universal basic income, if you take away the moral reservations about—what would they call it? The moral risk, right, becomes buyable.

    The sad thing is, is that any—the experiments that are being ________ aren’t real world. And what do I mean by that? They tried in Canada to ________. And I forget the details; I’ll mail it to your listeners if they want it. They’re running UBI on $1,000 a month. The test group got $1,000 a month. Well, gee, I mean, can you really live on $1,000 a month? That’s one thing. Whereas, if you go to another country that has universal basic income, and the poster child is Cyprus. Cyprus gives every citizen 500 Euros a month. The reason it’s relevant here is that a rent of an apartment in Cyprus is only 520 Euros a month. So, 500 Euros a month becomes, between—with two people, 1,000 Euros a month becomes a viable amount and a reasonable standard of living.

    That’s where UBI needs to be. We need to be starting to talk about UBI numbers in the area of $40,000, $50,000, $60,000 a year per family, and then we have to deal with the ramifications. And the ramifications really aren’t so much economic as they are social. What happens when you move the social structures that work bonds? In other words, what happens when a whole society no longer has to get up in the morning and go to work? What happens then?

    And that becomes the danger point, because most people have no idea.

    Shimel: Huh. Excellent. I think—yeah. I don’t disagree with you, there.

    Reselman: Well, again, I’m not looking for conflict or disagreement. This is a great discussion, but for our listeners out there, the point is—we are in technology. We are the people that write the scripts. There are other people that do the automation. We are the people that are making the robots. We’re doing all this. And we’re in a good position now, because unlike Henry Ford, who really didn’t think it through with regard to what an automobile would do over a period of 100 years, whereas one of the engineers at Sony did in terms of television. A friend of mine’s wife’s father worked at Sony, and he raised a question to one of his engineers back in—I think it was in the ‘80s. And he said, “You know, we’re selling a lot of Trinitrons. What are we gonna do when these all come back?” At least he posed the question.

    So, if anything, for the listeners out there that I hope they consider is, what do we do when we’ve become very good at all this? What do we do when we’ve created a framework and a fabric of automation where—and labor almost becomes unnecessary? What do we do, then? And what are the ideas behind that? And that’s where I wish there was more conversation, at the least. And not be on, “There will always be more jobs” or the fantastic stuff, but real, concrete, well researched conversation.

    Shimel: Excellent. Bob, I’d love to continue this conversation, but we are so way over our time. [Laughter]

    Reselman: Oh, I’m sorry, I’m sorry.

    Shimel: That’s okay! We’re gonna need to pick it up on another DevOps Chat.

    Reselman: Okay.

    Shimel: Which is great. I bet next month, we’ll do it again.

    Reselman: Sure, sure. Yeah. I’ll do that. I’ll make the coffee. The dog’s been very good here, he’s been very quiet. He understands that he’s being recorded, so.

    Shimel: Otherwise we’ll automate him out of a job. [Laughter]

    Reselman: Yeah. [Laughter]

    Shimel: Anyway, Bob Reselman—RoelBob, author, futurist, commenting on the state of the world today—thanks for being our guest on this DevOps Chat. We’ll continue this conversation on another DevOps Chat soon, but for now, this is Alan Shimel, and you’ve just listened to a DevOps Chat. Have a great day, everyone.

    — Alan Shimel

  • DevOps Chat: Modern Applications with SignalFx CEO Karthik Rau

    DevOps Chat: Modern Applications with SignalFx CEO Karthik Rau

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

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

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

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

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

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

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

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

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

    Rau: Yeah. Thank you.

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

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

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

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

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

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

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

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

    Rau: Yeah. Absolutely.

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

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

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

    Rau: Mm-hmm.

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

    Rau: Yeah, that’s right.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Rau: Thank you, Alan.

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

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

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

    — Alan Shimel

  • DevOps Chat: CI/CD with CircleCI’s Rob Zuber

    DevOps Chat: CI/CD with CircleCI’s Rob Zuber

    Microsoft’s recent acquisition of GitHub has spurred a lot of conversations regarding which company is the next big acquisition target, and here on DevOps Chat is no exception. In this episode of DevOps Chat, I speak with Rob Zuber, CTO of CircleCI about the CI/CD space, the future of the market and, yes, M&A activity in the DevOps space.

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

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat features Rob Zuber, CTO, CircleCI. Rob, welcome to DevOps Chat.

    Rob Zuber: Thanks. Good morning.

    Shimel: Good morning.

    Zuber: It’s a pleasure to be here.

    Shimel: Or afternoon, in my case, or evening. Who knows when people are listening to this? But, Rob, thanks for being our guest. I think this is the first time we’ve had anyone from CircleCI on a DevOps Chat here. So, you know, you are a mold-breaker and thanks very much.

    Zuber: I’m excited.

    Shimel: All right. So, Rob, our audience tends to be pretty DevOps-y, and so I’m assuming they know of CircleCI or at least have heard of CircleCI, but maybe they haven’t. So, in case they haven’t, Rob, give us a little background, just a real quick elevator, on CircleCI.

    Zuber: Yeah. So we’re a big part of the delivery pipeline for many software organizations. We offer continuous integration and continuous deployment, both as a cloud offering so that you don’t have to manage any of it yourself, but, if you’re interested in doing that, we also have a server-hosted version. And, you know, our objective is to help people focus on their business and get their software into market faster, taking out of the way the overhead of managing a lot of the tooling around doing that.

    Shimel: Yep. And, Rob, just in way of history and background and setting the table here, CircleCI really is – it was kind of a cloud-native CI/CD solution originally and it’s only relatively recently that you started having sort of an on-prem solution as well, offered as an option. So it’s kind of opposite of the usual SaaS migration, if you will, right, where people turn on-prem stuff into SaaS solutions. You were kind of a SssS solution and now offer an on-prem option.

    Zuber: Yeah, that’s exactly right. And that’s probably partly a function of when the company was started, so CircleCI launched in 2012. At that point, people were pretty comfortable with cloud offerings. GitHub had been around for a little while, so people were used to having the source code in someone else’s servers, and so we were able to leverage that a little bit. And we were able to grow quite effectively off of that base, but we did reach a point where there were very large customers with very specific needs, where it made a little more sense for them to run the software themselves and be able to have a little bit more opportunity to customize the environment in which it was being run, etc.

    One thing that’s interesting about that – and you talk about the difference in which way you go across that transition – because we built a multi-tenant platform from the beginning and really focused on our ability to operate that on behalf of other people, we find that, even in an on-prem solution, especially for very large organizations, we have a lot of the capability around that management at scale and centralized management that doesn’t – that still gives freedom to the individual developers to do their work. So it is actually quite interesting, how the genesis of the product affects how it operates in those multiple environments long-term.

    Shimel: Absolutely. Rob, another area – and I didn’t really talk to you off mic about this, but another area I wanted to explore was, historically, was CircleCI originally just CI or was it always CI/CD?

    Zuber: I think you could kind of look at that two ways. I mean, there was CD pretty early in the product, at least for some particular cases, but, if you look at the evolution of the software industry, many more people were doing CI in 2012 than CD. I mean, it was sort of this slow transition of people getting to, you know, “First, we’re gonna figure out Agile process and just how we do our actual software development. And then we’re gonna add CI on top of that. And then we’re gonna add CD.”

    So we always had some CD capabilities, but the number of our customers or the percentage or breakdown of our customers using CD has grown pretty significantly over that time, and I think that’s partly an effect of the kinds of tooling we’re offering, partly a shift in what CD even means, and then partly just growth in the market and comfort level of people doing that, right? Of – especially – and CD, of course, is always challenging ’cause some people are talking about continuous delivery and some about continuous deployment, but, in particular, on the continuous deployment side, other things had to come into play – you know, feature flagging, canaries, just better control of what it meant to actually put something in production. And so the comfort level and increase in that has led to more people using our platform for CD as well.

    Shimel: Absolutely. You know, as an observer of the space, sort of the market, I’d seen it come – when I first launched devopsy.kinsta.cloud, four years ago, Rob, there was this clear sort of distinction between “We’re not CD. CD is something else. We’re CI,” or reversed – “Those folks are just CI. They’re not CD.” And it kinda just seemed like an artificial wall had been built, right? Not to get all political.

    But – and so I, for one, am happy to see sort of that wall being torn down and the natural flow of the software development life cycle, of the modern software factory, if you will, taking place, where CI kinda naturally flows into CD. And I think the next thing we’re seeing is this natural connection to what Gartner and some of the others call “ARA.” Right? Which I don’t even know what the difference between that and CD is, but I don’t know. What do you think?

    Zuber: Well, I think that, overall, this evolution, as I was saying, it always takes a long time for people to get – or, let’s say, for everyone to get comfortable with each of these stages of the evolution. And we’re always looking to the next frontier, right? So, at one end of the spectrum, you have those early adopters, who, in 2012, were doing CD or before that. I’m trying to think of the original sort of posts around CD that I think came out of, I wanna say, Etsy, but I don’t know if that’s actually true or me projecting kind of them as a pillar of this type of thinking. But, you know – and we’re still at a point where some people are just getting comfortable with and adopting it, so the spectrum is really broad, from early adopters to sort of overall mass adoption.

    And the early adopters have moved on to, probably, things that I haven’t even thought about, and so we’re always seeing that and it’s nice to have people try those things and, in some cases, fail, and, in some cases, discover really new and interesting ways of approaching stuff. And it takes – it definitely takes a little bit of a mindset of “I’m just willing to try this. I’m willing to take some risk and do new things,” and the people that do those create opportunities for the rest of us to learn from, the things that go well and the things that go horribly wrong.

    And so it’s one of the reasons that I just love being in the space in general, is just the constant kind of desire to do things better and find new opportunities, of course, with a good balance towards actually focusing on getting stuff done, but there’s just such a creativity and desire around improving, in any way we can, this process and how we get stuff out and how we build it reliably and work efficiently.

    Shimel: Absolutely. So, Rob, let’s turn a little bit to – we’ve done a nice history. Let’s look a little bit to the future now, though.

    Zuber: Mm-hmm.

    Shimel: Talk to me – what did – how – you’re the CTO. You kinda have a lot of the vision for CircleCI. Where do you see CircleCI and the market in general going?

    Zuber: Yeah. Well, that’s a great question. I think a lot of people’s perspectives of this market was changed a little bit in the last week or so, with news around Microsoft and GitHub and just the value that people are starting to recognize in developers, the happiness of developers, the efficiency, the value that they place on the tools that they use. So, for the market overall, I think we’re just a really exciting time, where we talked about this – or I talked about this creativity and passion to do things better, but we’re at a sort of inflection point where there’s a really, really high-level recognition of the value of that.

    I would say there’s been a significant shift in the mentality of many companies. And we talk a lot about how every company is becoming a software company, in that, even if you’re an airline, your biggest issue, when you ground your planes for a day, is that you have some software glitch somewhere, right? You know, multinational trading markets are shutting down on software issues. So the impact and value of software is becoming really, really visible and, as a result, there’s a shift in mentality about how we build software, from “This is a cost center that I just have to manage down,” to, “This is the core of my business and I need to be really investing and doing this in the best possible way.”

    And so that’s obviously exciting for us. And one of the things that’s really interesting for us, as we look forward, is that we – we’ve had the fortune of some success and growing and, to the best of our knowledge, run the largest or one of the largest build platforms on the planet. As a result, we know a lot about how people are building software, and so we’re investing a lot of our time and energy in figuring out how to use that to then help those people, meaning, if you’re building on CircleCI, you don’t just get an understanding of your particular code change that you just made, but you can get an understanding of how your team is doing, how your whole process is doing, how effective you are, relative to other teams out there.

    And I think that’s a place where we have a lot of opportunity to really add additional value for our customers, in not just, again, direct feedback on this one thing that you did today, but really helping understand your process, maybe where things aren’t working well, maybe where you have some opportunities to improve. We’re all in this, trying to be better every day. And if we can help customers at that at a higher level, that’s really exciting for us.

    Shimel: Yep. You know, it’s interesting you brought up the GitHub thing and to justify all this. And so I have some views on it. What a surprise. But, you know, Rob, couple things. No. 1, when you look at GitHub and the price Microsoft paid, it obviously is a ridiculous multiple to revenue. I saw a chart earlier today. I forgot if they said it was 21 or 24 times revenue, which is wow. Right? That’s why people do software companies.

    But another way of looking at it is, look, Microsoft has always coveted the developer community. And, over the last – I mean, for as long as I’m in technology, 25, 30 years, they’ve done not a crappy job of working with the developer community. Yeah, there are haters and Linux folks and the open source, when Ballmer was there, you know, but they’ve always gone after the developer community hard. And so they had an opportunity to buy a company that has, some estimates say, 28 million people or potential developers, right, in that community that GitHub has. So, when you look at 28 million and what they paid – don’t get me wrong; it’s still a lot of money, but it’s a little bit – you could see where they saw the value, okay?

    Zuber: Mm-hmm.

    Shimel: No. 2, having been in the tech, software infrastructure business a long time, I learned a lesson from my friend Brad Feld, who I sold my first company to and he financed or was one of the key VCs behind many of the companies I’ve been involved in, and that is, look, first mover or first – not the first mover, first acquisition in the space always gets the lion’s share and the best multiple. The second one does okay. The third one does a little worse. If you’re not in the top three, don’t bother. Right? That was something Brad always preached to us.

    So, when you look at Git – or GitHub, excuse me, being the first kind of acquisition in that space, getting this kind of multiple, they deserve it. Right? They were first. They were the first ones bought; they’re gonna get the lion’s share. I think the message to other folks in the GitHub space, specifically, is “Hurry up and get bought ’cause you don’t wanna be number four or five.” Right? You don’t wanna be left in the musical chairs game when the music stops.

    Part and parcel of that, though, Rob, is that companies like Microsoft, like IBM – we used to say “like HP, Cisco,” you know, big, big public entities – it’s very hard for them to be innovative. It’s very hard for them to do their own R&D. It’s very hard for them to build these communities themselves. And so what they would spend in R&D or community actually goes into their M&A budget and they buy those things.

    Zuber: Mm-hmm.

    Shimel: So, when we look at a GitHub, we look at a CircleCI, we look at any – a Chef, a Puppet, any of the – even the Jenkins or CloudBees, any of the players in this DevOps space that is so hot right now – GitLab, another one – they all are gonna be very attractive to companies of a Microsoft kind of girth. Right? Because the big guys can’t – they can’t do what you’re doing, Rob. They don’t –

    Zuber: Yeah.

    Shimel: You know.

    Zuber: Yeah. I mean, I think this is classic innovator’s dilemma, right?

    Shimel: Yeah.

    Zuber: Did I get that right? So it’s difficult. I mean, if you look at the first five year – I mean, we all talk about these overnight successes, right, and they always – they’ve been around for 10 years. And the first five years many of those companies is extremely painful, it’s a grind, and the incremental increase, the amount of revenue you’re driving or whatever, would be so insignificant on any one of these companies’ radar that they just – they won’t put the time and energy into it, right?

    Whereas you’ve got a company like ours or anybody in the space, honestly – I’ve done a bunch of different startups in different spaces – you’re living and breathing it, right? And you’re so tuned into what’s happening that you can see it. And that kind of incremental growth, to you, is everything and it’s super exciting and you get this passion behind it that allows you to build a very focused and, honestly, a great product. And I think GitHub is a great product. And then, suddenly, you have 28 million users – I’m quoting your number so I’ll assume you’re right –

    Shimel: _____ I’ve seen.

    Zuber: And a massive community. You know, and then, going back, as you were talking about the time and tech, I mean, I got into tech with the quarterly mailing of MSDN CDs and, honestly –

    Shimel: Exactly. Yeah.

    Zuber: – my favorite IDE – I’m a Mac and Linux user, almost exclusively, but I used Visual J++ in the late ’90s, when I started doing Java development. It’s still the best IDE I ever used. So Microsoft has been good, very, very good, with developers, but the kind of developer community has started to drift away from where they were going. And so this is – I wouldn’t call it a course correction because they still have all of their community, from a .NET and sort of Windows world, but this is an opportunity to be less about Windows, you know? And we’ve seen Microsoft shifting away from –

    Shimel: Oh, yeah. Satya Nadella’s Microsoft, Rob –

    Zuber: – just pure kinda _____ –

    Shimel: Not to step on you, but Nadella’s Microsoft is a very, very different place than when Steve Ballmer was there. Right?

    Zuber: Yes.

    Shimel: And they are moving to Azure and though Azure does Windows well, it does containers well, it does Linux, it does – you know, there’s very little it doesn’t do.

    Zuber: Right.

    Shimel: You know? And I will tell ya – I’ve told people this – I think, one day, Microsoft buys Docker. That’s my personal opinion. I think it’s another kind of – not to get into it or badmouth or anything like that, I just think someone’s gonna buy Docker ’cause the revenue has to justify the valuation, and so – and Microsoft’s a great candidate to do so. But, anyway, you heard it here first. But, Rob, that’s all fine and dandy. GitHub plays in sort of a different segment of this DevOps market than you guys do, certainly.

    Zuber: Mm-hmm.

    Shimel: And we really haven’t seen the consolidation yet, that I think we will in the CI/CD and, if you wanna call it, ARA space, but it’s coming. I’m sure.

    Zuber: Yeah, we’ve seen movement in the market, but most of it has been off the bottom end, if you will, meaning sort of the smaller people we would consider to be our competitors but didn’t quite reach critical mass and then got pulled in by other companies, for the people or because the product was going to be useful to them internally, that sort of thing. Not a roll up and now we’re taking this and getting it scales or _____ –

    Shimel: So we used to say, when I worked with Brad, those are companies that really were a feature, not a product.

    Zuber: Mm-hmm.

    Shimel: But, with that being said, Rob, we went off on a little bit of tangent here. We’ve used up way more time than we were supposed to. But maybe we could have you back on and – ’cause I wanted to really get into a little nuts and bolts around continuous integration, delivery, what it means for developers, what it means for ops folks, but why don’t we do this? We’ll call it a day on this 25-minute DevOps Chat and we’ll have you back on maybe next month. And let’s get into what it means for developers and ops folks in even testing, in this new world of CI/CD.

    Zuber: That sounds great. I’m always happy to talk about that as well. There’s so much happening in this industry, in this space right now, that it’s hard to keep it short. [Chuckles]

    Shimel: You know what? Hey, man, it keeps my kids going to college, Rob. [Laughs] Anyway, hey, Rob, Zuber, CTO, CircleCI, this episode’s guest on DevOps Chat. Thanks for joining us. This is Alan Shimel. You’ve just listened to another DevOps Chat. Have a great day, everyone.

    — Alan Shimel