devopsy.kinsta.cloud

Author: Alan Shimel

  • DevOps Chat: Jez Humble Discusses 2018 ‘State of DevOps Report’

    DevOps Chat: Jez Humble Discusses 2018 ‘State of DevOps Report’

    DORA’s annual “State of DevOps Report” is something I look forward to every year. There is no other report out there that gives us a view and insight into the industry the way this one does. And I know I’m not alone in my beliefs. That’s why it’s always a treat to speak with one of the folks from DORA—DevOps Research and Assessment—about the “State of DevOps Report” and get some real takeaways.

    In this DevOps Chat, Jez Humble, CTO and co-founder of DORA, and I talk about some of the findings in this year’s “Accelerate the State of DevOps Report”—a new name, but the same valuable information.

    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 is one I look forward to every year and that’s the one where we speak about the latest “State of DevOps Report.” Helping me, or actually our guest and star for this year’s “State of DevOps Report” review, is none other than Jez Humble, co-founder, CTO for DORA, DevOps Research and Assessment and just all-around DevOps dude and great guy to talk to. Jez, welcome to DevOps Chat.

    Jez Humble: Thanks so much for having me, Alan. Always a pleasure.

    Shimel: Thank you. And Jez, you know, you guys, Nicole and you and Gene and the rest of the team have done another bang up job this year in the “State of DevOps Report.” It has a little bit of a different nomenclature this year. It’s actually – if I mess it up, correct me –”Accelerate the State of DevOps Report”?

    Humble: Yeah, that’s right. It’s the “Accelerate State of DevOps Report” this year but continuing the same rigorous research as previous years and extending it with some exciting new findings this time.

    Shimel: Yeah. And another thing I will mention, right, let’s get it out of the way early on, is that this year’s report diamond sponsor is Google Cloud, correct?

    Humble: Yep, that’s right. We have 15 gold sponsors as well, but our main collaboration this year is with Google Cloud. That’s correct, thank you.

    Shimel: Fantastic. All right, now that we’ve got the commercial out of the way, Jez, let’s dive in. So this is what, the fifth or sixth year you guys have worked on State of DevOps Report?

    Humble: Yeah, so this is the fifth year that DORA has been involved in or been leading the research for this State of DevOps Report. That’s correct.

    Shimel: And so, you know, when we look at it from that point of view, you know, with hindsight, it really is a massive amount of data there to dig into, but let’s concentrate on this year’s report, Jez. Let’s start with what do you think for our listeners, what do you think the biggest takeaway for them is?

    Humble: So yes, as you say, this is the biggest research program of its kind looking into DevOps, what DevOps means, why it’s important, the factors that predict your ability to deliver with speed and stability. You’d think, you know, this is the fifth year that we’re doing this that we’d run out of things to talk about. That’s absolutely not the case. This is the biggest and most comprehensive one yet. I think a few big takeaways.

    No. 1, again, we found that our measure of software delivery performance is still valid. That’s looking at speed and stability. We find again that the high performers are not trading off one against the other. They’re actually increasing both the speed and stability of the delivery process. We’ve extended that measure out also to look at availability as well. So availability is availability in production. It’s a measure of operational performance. Because we’re also looking at that, we now talk about software delivery and operational performance. So we’re covering the whole delivery life cycle from development right through to operations in production. Again, we find the high performers are not making trade-offs there. They’re achieving high levels of throughput and stability and availability as well.

    We’ve also looked at the key technical practices that drive high performance, and we’ve expanded that this year to also look at monitoring and observability to look at the impacts of continuous testing, to look at database change management, and to look at shifting network security. We’ve also looked in more depth at culture. We’ve looked at the management practices that shape culture to improve performance outcomes. This year we’ve also looked at the role of leaders on influencing culture through giving their teams autonomy and building trust. We find that promoting a culture learning fostered through retrospectives learning reviews has an impact on culture. The highest performers are 1.5 times more likely to consistently hold retrospectives and use them to improve their work which is critical.

    We also looked at cloud infrastructure. A lot of people are moving to the cloud. That’s very hot, and it’s seen huge adoption across many different industries, but what we found is that how you do it matters. Now the National Institute of Science and Technology has a definition of cloud infrastructure and they talk about five essential capabilities that you have to implement – things like on demand self-service whereby customers can unilaterally provision cloud resources. We find that high performers are 23 times more likely to be using those five essential characteristics that NIST talks about. So there’s lots of people who are using cloud but don’t actually have those capabilities implemented. That’s a problem. How you do this stuff matters. Just putting your stuff in the cloud and pretending it’s a data center doesn’t actually work. You need to actually use the capabilities the cloud provides as well.

    We found that using open source software improves performance. And finally, again, we’ve shown that industry doesn’t matter. We find high performers among all different market groups, all different industries whether that’s financial services, health care, other highly regulated groups, as well as, you know, startups and small companies in the low performing groups. So anyone can do this stuff.

    Shimel: Absolutely. [clears throat] You know, Jez, I find it not comforting but we hear you talk and you talk about, well, companies that are moving in the cloud and stuff. You know, I guess was it around maybe 2005 where all of a sudden the cloud really started kind of bursting on the scene and here we are 13 going on maybe 15 years and, you know, it’s almost like, well, when will we really see – are we in the midst of like the – it’s mainstream certainly, but have we seen – where are we in cloud migration and how this is impacting us? Like has the bulk of it already taken place or is the bulk of it in front of us?

    Humble: Yeah. I mean that’s a great question, and I think we see the same trend with DevOps and with, you know, continuous delivery as well. People say they’re doing and the question is are they really doing it because everyone wants to do it and then say they’re done and what’s the next big thing? I mean if we look at our data, what we see is 17 percent of respondents are not using cloud at all and the rest which is 83 percent are using cloud including 40 percent using multiple cloud providers. But if we look at who’s actually doing it right, only a very small proportion of people who actually say they’re doing it in fact are. Twenty-two percent of our respondents said they met all those essential characteristics. So I would say that there’s some way to go. I mean it’s literally the Pareto principle, right? Eighty percent of people are doing it; only twenty-two percent are doing it right.

    So I think there’s a long tail with all this stuff. Whether it’s DevOps adoption, whether it’s cloud adoption, we’re all learning as we go along. Change takes time. It’s hard. To do this stuff right you need – and this again is common across tech and DevOps – you need to change the way you do things. You need to change your practices. You need to change your processes. That’s hard and that’s the bit that takes the time. It’s complicated. People are very keen to adopt new technologies, you know, Kubernetes, Docker, Cloudstaff, and they adopt it; but changing their processes and practices, that’s the hard work; but it’s also the important work. We see that very clearly in our research.

    Shimel: Yeah, yeah. And you’re right. I mean I’ve often thought that, you know, there’s a chicken and egg relationship between DevOps and many of the megatrends that we’ve seen pop up over the last decade including the cloud and ubiquitous connectivity and the move to mobile, you know, and application driven sort of IT world. I don’t know, you know, if any one of those things happens without any of the other things including DevOps, frankly, which makes this so important. So Jez, when we look at this year’s findings in historical perspective to previous years, any kind of anomalies, anything that jumps out that says, boy, this seems different than years before, this seems kind of not to be moving along that same track that we’ve seen in years before?

    Humble: Yeah, great question. So a few things. Firstly, we’ve got a new high performance group, the elite performers. So in previous years, our cluster analysis has shown us that there’s three groups – high performers, medium performers, low performers. So when we did the cluster analysis this year, we found a couple of interesting trends. So firstly, we’ve got an elite performance group which shows that the industry continues to improve its software development and delivery practices.

    And our high-performance group has grown in terms of the percentage of respondents which shows that high performance is attainable for many teams in the industry, not just reserved for an exclusive group of teams with unique characteristics. So high performers continue to deliver and operate software at the highest levels, but the bar for excellence has continued to evolve across the industry and this fourth group of performers, elite performers is still optimizing and getting better. That’s what we see in general. The best organizations are the ones that keep trying to get better and are never satisfied.

    The other interesting trend we saw with the cluster analysis was we found that a small group, about 7 percent that we’ve called the misguided performers. So the misguided performers is interesting as well. So this is a group that’s basically optimizing for going slowly. They’re making safe choices but they pay a really expensive price. So they’re taking this very cautious approach, and they want to release infrequently, and they see that as an effective strategy and that extra time between deployments for testing and quality checks, but they report really long times to restore service when there’s outage like months and months of time to restore service which is a huge problem.

    So our research shows that making large batch, infrequent changes introduces risk to the deployment process; failure is inevitable in complex systems; and when large failures do occur, these big batch changes can contribute additional complexity when attempting to both understand failures or when dealing with catastrophic or cascading failures through the system. Sorry, 5 percent of teams that are doing exactly this and seeing the consequences. So those are kind of some interesting things that we saw in this year’s data.

    Shimel: Absolutely. So you know, Jez, certainly since the founding, the creation, the launch of DORA, the survey has taken on not a greater mission but it’s so intertwined with what DORA itself does, right, to a large degree. And I don’t know if our audience – I think they’ve all been reading this survey for years. They may have had heard of DORA. They know Nicole. They know you. They certainly know Gene. But lay it out. Connect the dots for us. How does the survey go sort of arm in arm or hand in hand, whatever the case may be, with DORA and its mission.

    Humble: Yes. So our mission, as DORA, DevOps Research and Assessment, our mission is to help the industry create excellence in software delivery. We really want to help organizations get better. We have a product. Our product is an assessment tool that can help you see how you’re doing and see what the constraints are in terms of your ability to get better. There’s a bunch of assessment products out there. We really wanted to take a scientific approach to this. So four years of doing this previously with Puppet and now doing it with Google led by Nicole – Nicole was an academic. She was a tenure track professor. She has a long background in research from an academic point of view. She really has found a way to work out what matters in an academically rigorous way that’s scientific.

    All this research we’ve been doing actually allows us to say, here’s how you measure performance, here’s how we can show it has an impact on the organizational outcomes you care about, here are the things that predict your ability to lever with speed and stability and that’s a combination of technical and cultural and process based capabilities. So we can say these things actually matter. So here are the things that matter. Here’s how you measure them. Here’s how they impact your software delivery performance, and here’s how that predicts the organizational performance. So it’s really about taking a scientific approach to measuring these things and improving them.

    Actually this year we came out with a book, “Accelerate,” which talks about that research program and the results we found over the last four years of doing that program. So it’s all about taking a scientific research based approach to improving technical capabilities around delivering software.

    Shimel: Absolutely. Absolutely. And Jez, believe it or not, we’re almost out of time already. As I mentioned, it does go quickly. But I want to do a little bit more on DORA for people who don’t get it. I know you’ve worked publically – I think it’s announced DORA’s worked with Capital One among other enterprises. Give our audience, you know, again, a little bit more about DORA’s mission and how you’re helping companies there.

    Humble: Yeah. Well, I mean thanks very much for the opportunity to talk about this. We have a solid number of companies who are our customers from all kinds of industries including very large, highly regulated industries including finance and government who are interested in finding out how to get better. We basically apply our research that we’ve gathered over the last several years and help them understand what’s holding them beck, what their constraints are, and then how to actually improve that in a research databased way.

    So it’s something that applies everywhere. It’s something that applies – and this is one of the great things about this research is that it shows that anyone can do this stuff. So this applies anywhere. You know, I’ve often heard people say, “You know, well, we can’t do that. This won’t work here. DevOps, whatever cloud, continuous delivery, it sounds great, won’t work here.” And we can really come in and say, “Well, actually, you know, that’s really not the case. Anybody can get better, and here’s how the data shows that people in all kinds of different industries of all different sizes can improve.” And again, we’ve been able to help companies actually find out where they are and find out their constraints and understand how to improve.

    It’s been very helpful from that perspective, not just – and this is a great think about working at DORA that I love is that not only is it scientific and research based, it’s also pragmatic and practical and it has real impact on the ground with companies looking to improve their software and development capabilities. So it’s really a total pleasure and great fun being able to not just do the research but also apply it in practice. That’s a real privilege for me being in that position to be able to apply this in this way.

    Shimel: Absolutely. Well, Jez, you know, continued success with DORA and I’m looking forward to – oh my god, I forgot to mention, Jez, if people want to download the report, where can they go get it?

    Humble: Yes, thank you so much. That’s an excellent question to ask. So you can go to our website. DevOps-research.com. If you go to the research, it’s on the front page. It’s on our research page. The link to download the report from Google Cloud. You can also go to bit.ly/2018-devops-report. That will take you straight to the registration page so you can download the report. Also a reminder that we’ve discussed the last four years of our research and our research program in Accelerate, the book that we came out with earlier this year. But yeah, please go and look at the report. Obviously, we’ve only been able to touch the tip of the iceberg in this discussion. There’s loads of, if I say so myself, very interesting stuff there. So encourage you to go and download it and check it out.

    Shimel: Absolutely. All right, Jez Humble, always a pleasure, my friend, to have you on our show. Thank you very much for doing the report. Continued success. Say hello to Dr. Nicole and Gene and the rest of the gang and we’ll have you back again soon on DevOps Chat.

    Humble: Thanks so much, Alan. Always a pleasure. Thank you.

    Shimel: My pleasure. This is Alan Shimel for devopsy.kinsta.cloud, DevOps Chat. You’ve just listened to another chat. Have a great day everyone.

    — Alan Shimel

  • DevOps Dozen 2018: Nominations Deadline Approaching

    DevOps Dozen 2018: Nominations Deadline Approaching

    The last day to submit your nominations for the DevOps Dozen 2018 awards is Oct 10. Click here to vote.

    This year’s awards will include 12 categories, with a winner chosen from each. The top four to six nominees in each category will become finalists, who will be selected based upon the number of nominations they received. You can nominate up to two entrants in each category; however, you can make only one nomination per person. In addition, everyone nominating will be required to provide their name and email address; while that won’t thwart any ballot-stuffing, we hope people will be trustworthy during the nomination process. The winners will be selected by our panel of judges.

    Who are the judges? This was tough. We couldn’t have anyone who might be eligible for an award. That disqualifies vendors, practitioners and many others. However, I think we have four great judges:

    1. Alan Shimel, founder and editor in chief, devopsy.kinsta.cloud
    2. George Hulme, longtime tech journalist and editor at devopsy.kinsta.cloud and Security Boulevard
    3. Jayne Groll, CEO and co-founder of the DevOps Institute
    4. Helen Beal, DevOpsologist at Ranger4.

    So what are the dozen categories for the DevOps Dozen this year? That you can get on the site itself, but here they are as well:

    [su_custom_gallery source=”media: 125437,125438,125439,125440,125441,125442,125443,125444,125445,125446,125447,125448,” link=”custom” target=”blank” width=”400″ height=”200″]

    Thank you again for your enthusiastic response to last year’s awards. The full list of 2017 finalists and winners are available to view here.

    There are so many great companies and people involved in DevOps that it’s always difficult to pick the winners. We know some worthy choices will not be voted tops in their category; however, acknowledging them in our awards process helps show how important they are in the DevOps space.

    As stated earlier, the top four to six nominees in each category will be designated as finalists, who then can submit a presentation on why they deserve the award to judges@devops.com. Finalists will be announced the second week of November and the winners, who will be chosen by our panel of judges, will be announced in December.

    If you have questions, send them to DD@devops.com. Voting for finalist nominees is open for three weeks, so don’t waste any time—nominate your favorites today. Good luck to everyone vying to be one of the DevOps Dozen 2018!

    — Alan Shimel

  • Mainframes and DevOps: The Odd Couple of Digital Transformation

    Mainframes and DevOps: The Odd Couple of Digital Transformation

    I am still surprised when I go to industry conferences and I hear people talking about the imminent demise of the mainframe. More common and equally wrong is how mainframes don’t work in today’s agile/DevOps/cloud/container world. The fact is, with trillions of dollars invested in our mainframes and more every day, the mainframe is not going extinct anytime soon. Equally factual is mainframes and DevOps can work well together.

    They may seem incompatible at first blush, but mainframes and DevOps work. We have written more than several articles on mainframes and DevOps. Our own Don MacVittie has written two excellent ebooks on mainframes and DevOps: “DevOps-ing the Mainframe” and “Automation: Modernizing the Mainframe for DevOps.” There is also a series of DevOps Chats on this subject. This one, with Rosalind Radcliffe of IBM’s Enterprise Systems, is a good one.

    Now, we would like to hear from you. What do you think regarding mainframes and DevOps? Working with our friends at CA Technologies’ mainframe business unit, we are conducting a mini-survey (just 10 questions) on mainframe use. It is embedded below this paragraph. You taking a few minutes to answer will help us better understand what is happening with mainframes and DevOps.

    The Mini-Survey

    Create your own user feedback survey

    If the survey embed didn’t work for you, you can also answer the 10 questions right here.

    If you’ve reached here because you took the survey, thanks very much. If you didn’t, please take a moment and do so. The survey doesn’t ask for any contact info and we promise you won’t receive any spam email or calls.

    Still would rather not answer the survey? OK, at least have a look at the ebooks listed above or listen to the chats. But, if you really think mainframes are going away or you have an opinion on mainframes and DevOps in general, you can write me at editor@devops.com. I would be happy to hear about it. Perhaps you want to write an article about your views? That is fine, too—write me.

    In the meantime, next time you are at a tech conference and the issue of mainframes and DevOps comes up, don’t spread fake news. The mainframe is alive and well. More of our financial, health and other transactions as well as systems of record go through them than ever before.

    — Alan Shimel

  • 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

  • GitLab Joins Unicorn Club With $100m Raise

    GitLab Joins Unicorn Club With $100m Raise

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

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

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

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

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

    [wpvideo lvF0Ey0B]

    — Alan Shimel

  • 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