devopsy.kinsta.cloud

Category: Features

  • DevOps Deeper Dive: BMC Software Bets on AIOps Transformation

    DevOps Deeper Dive: BMC Software Bets on AIOps Transformation

    As BMC tests the AIOps waters, the company seeks to find a balance in serving both the DevOps and ITIL populations

    It’s clear in the enterprise IT space that artificial intelligence (AI) is poised to play a significant role in IT operations, a phenomenon known as AIOps. Often with this level of IT disruption, new entrants funded by venture capitalists flood the segment, leaving incumbents to either fend off the new rivals, cede ground or, in many cases, put an end to the threat by acquiring one or more those startup companies that pose a threat to their existence.

    In the case of BMC Software, it has decided to stand its ground by aggressively investing in AIOps research and development. Most recently, BMC extended the AIOps capabilities of its existing portfolio of TrueSight IT management software through additional advanced analytics to identify patterns and anomalies within an IT environment. Other examples of BMC employing machine learning algorithms to automate IT environments tools include the ability to surface continuous recommendations for cost optimizations and automated event remediation workflows that promise to reduce the mean time to repair (MTTR).

    BMC has been making a case for AIOps as far back as 2017, but it’s only now that many organizations have enough confidence in AI to start embracing AIOps beyond the pilot stage. The challenge organizations face with AIOps are both technical and cultural: It requires a significant amount of time and effort to train and tune an AI model of each customer environment.

    [su_box title=”BMC Software Milestones”]

    • Dec. 2016: Peter Leav succeeded Bob Beauchamp as president and chief executive officer. Beauchamp remains chairman of the board of directors.
    • Oct. 2017: BMC Launches First AIOps Initiative for TrueSight
    • Nov. 2017: BMC Refinances Debt
    • Oct. 2018: BMC Software Goes Private After Being Acquired by Investors
    • Feb. 2019: BMC Partners with IBM on AI
    • April 2019: Bob Beauchamp resumes role as CEO
    • June 2019: BMC Extends AIOps Capabilities of TrueSight

    [/su_box]

    In addition, the effectiveness of any AIOps model varies based on the complexity of the IT environment. Organizations also should be concerned about the potential impact any flawed AI model might have on IT operations—it’s one thing for a human to make a mistake, but an AI model making a mistake at a level of scale could be catastrophic.

    From a cultural perspective, not every organization is yet comfortable with those AI models on current staffing, which can make some members of the IT staff less than comfortable with the whole concept.

    BMC CEO Bob Beauchamp

    It is early days for AIOps in DevOps processes. But the increased complexity of modern IT environments based on cloud-native technologies will force the issue within most organizations. BMC’s challenge is that while its management platform is employed widely in IT environments relying on ITIL-based frameworks, its footprint is comparatively nascent within organizations that have embraced best DevOps practices.

    Bill Talbot, vice president of solutions marketing for BMC, said one of the company’s advantages is access to the massive amounts of data required to train an AI model effectively. Most startup companies in this space don’t have nearly the same depth in terms of customer base, he said. That puts BMC in a better position to employ big data analytics to identify patterns and trends across multiple customers without having to know what data came from any one specific customer, unless the customer elects to share its data with BMC.

    BMC makes it a point to caution customers about rivals that make AIOps claims about their platforms but don’t actually solve a specific problem—a process known as “AIOps washing.” An AIOps platform not only needs to leverage Big Data analytics and machine learning, but it also provides the code and functionality needed to customize specific IT operations use cases, including capabilities such as automated event remediation and service resolution, optimized cost and capacity management and proactive vulnerability mitigation.

    BMC Software today stands at a crossroads. The company recently brought back former longtime CEO Bob Beauchamp to run the company day to day and has made no secret of the fact it is looking for additional investors. Making a pivot to AIOps requires access to massive amounts of funding for incumbents and startups alike.

    The next BMC act undoubtedly will involve employing AIOps across both DevOps and ITIL-based environments running on-premises and in the cloud. By any measure, that effort represents one of the most ambitious transformations ever attempted by any IT vendor.

    — Mike Vizard

  • Digital Transformations Fall Short, Survey Claims

    Digital Transformations Fall Short, Survey Claims

    What is the nature of digital transformation? Is it a permanent shift in the digitization of business processes, or a race to a known destination? Should organizational investments in data analytics, continuous software development, business processes, culture, machine learning and shifting enterprise technology from a perspective of ownership and control to consumption be judged from the eye of the consumer?

    The answer seems straightforward. Eventually, the market is the ultimate arbiter of digital transformation success. However, many organizations today are busily investing in technologies they hope will serve them well in the years ahead, and some of the largest investments are not immediately visible to consumers.

    According to the Kony Digital Experience 2019 Index Survey report, businesses are “still missing the mark” with consumers despite nearly $5 trillion in digital investment. The report didn’t distinguish how the $5 trillion was being spent and in what areas of the business the investments were made.

    “As companies race toward digital transformation, their leaders might want to hit the pause button and reassess their efforts. The significant investments by companies around the world to transform their business to become more digital has had very little impact on consumer experience,” according to the report.

    Perhaps—or, perhaps, many organizations are laying their groundwork and it’s way too early to make such a call.

    According to the survey, customers (65%) are more satisfied if their digital experiences feel effortless (who wouldn’t?) and 63% of customers said they would spend more money if their digital experiences feel effortless. Of course, history is full of surveys detailing consumers stating how they’d act but consequently end up acting entirely differently; people are notorious for answering surveys how they think they should answer or how they wish they would act rather than how they do act. Famous examples include surveys on privacy, security and personal finance.

    The findings of this survey are based on 1,600 respondents across the U.S., Europe and Asia. According to Kony, 800 were participants or leaders of digital transformation initiatives in organizations with 500 or more employees.

    The study focused on business investments and customer experiences within the banking, retail, utilities and healthcare industries.

    Interestingly, respondents said organizations in banking (54%), retail (59%) and utilities (51%) are keeping pace with their expectations but are not delivering differentiated digital experiences. The big laggard was health care, with only 48% keeping pace and 20% being behind respondents’ expectations.

    The study concludes businesses are not listening to—or understanding—the evolving needs of their customers because only 28% of enterprise digital transformation initiatives are started specifically with customer needs as the priority.

    “Improvements in costs and efficiencies are always welcomed and clearly important to project funding, but the real returns and real impact of digital starts and stops with its impact on the customer experience,” said Thomas E. Hogan, chairman and CEO of Kony Inc.

    That’s an incomplete way of looking at what is happening when it comes to digital transformation and the scope of technological change underway. That figure and comment are based on the survey findings that 68% of digital transformations were business process-centered, 4% employee experience-centered and 28% customer experience-centered.

    My take: In most cases, business leadership knows what they need to do and where they need to place their primary focus. And it’s a tough call to broadly state businesses are missing the mark without looking at how specific businesses are choosing to invest, as well as their stated objectives. Such information was not available in the survey.

    In many—if not most—cases, businesses are focusing on what they need to do, such as eliminating technical debt, automating business processes with robotic processes, streamlining their development pipelines and more. Of course, it’s essential to provide quality experiences to customers, as the survey found 47% of consumers will consider switching providers if their current provider doesn’t deliver the digital experience they demand and expect.

    That said, it’s not always true that digital transformation begins and ends with the customer. Large enterprises have decades worth of technology investments they must manage, and successful digital transformation isn’t a set finish line that enterprises are rushing toward. Rather, it’s a never-ending continuum, and those enterprises that are investing in the removal of technical debt, modernizing their software delivery methods, machine learning and streamlining their businesses to be more cost-effective and agile are building platforms that will sustain their businesses and provide exceptional digital experiences over the long haul.

    — George V. Hulme

  • 3 Reasons Why DevOps Is More Popular Than Ever

    3 Reasons Why DevOps Is More Popular Than Ever

    How popular is DevOps? More popular than ever, if Google Trends is to be believed. Here’s a look at how the popularity of DevOps has increased over time, and what has driven the change.

    The Spiking Popularity of DevOps

    Here’s what Google Trends tells us about interest over time of the term “DevOps” over the past 15 years:

    And here’s the data for the same term over the past five years:

    As you can see, talk about DevOps began circa 2010 and increased steadily thereafter. But it wasn’t until early 2019 the interest in DevOps sharply increased.

    Granted, Google Trends is a crude, closed-source data source. And interest in DevOps as measured by Google is certainly not a straightforward representation of things such as the economic importance of DevOps or the influence of DevOps within programming communities specifically (as compared to within Google’s user base as a whole).

    Why is DevOps More Popular Than Ever?

    Still, I was surprised to see such a large and sudden spike in interest in DevOps starting early this year. I can’t think of any singular event that explains the trend. But I can think of several longer-term factors that, when added together, probably have been responsible for ushering in a world where more people than ever are talking about DevOps.

    One is the fact that DevOps finally seems to have made its way into mainstream computer science and IT education. Here, I’m speaking a bit anecdotally. I’m not aware of any surveys of how many universities overall include DevOps in their curricula. But I can attest it is at least mentioned in some of the CS and IT courses at the technical university in the U.S. where I teach. To my knowledge, this was not the case just a few years ago.

    What this means is the university is now graduating students who are already familiar with DevOps as they enter the workplace. They are spreading the gospel of DevOps to organizations that have not already heard it, and they are reinforcing it where it is already present.

    Another factor at play, I think, is the market for DevOps tools has matured and consolidated. Even just five years ago, most companies talking seriously about DevOps were startups. Now, many of those startups have become hugely successful independent companies (such as Slack) or have been acquired (such as Wercker or Electric Cloud) by larger organizations.

    To be sure, plenty of other DevOps startups have failed or stalled. But the fact that others have succeeded spectacularly has done much to drive continued interest in DevOps.

    Last but not least, the tooling for DevOps has matured along with the market. Circa 2010, when the conversation about DevOps was getting started, it was much easier to talk about de-siloing your IT organization than it was to break down the silos in practice. At the time, DevOps-friendly collaboration tools had not yet gone mainstream. Release automation suites were also mostly limited to PaaS-style offerings whose features amounted primarily to automating deployments. They lacked the end-to-end integration, testing, building and management features of modern DevOps release tools. And many of the more advanced DevOps release platforms were built by startups, which made adopting them somewhat risky (because you could end up with a platform of a vendor that went out of business suddenly).

    Today, in contrast, there is a litany of mature, feature-rich CI/CD tools to choose from—not to mention communication and collaboration solutions such as Slack and GitHub. It’s very easy to build a DevOps toolset, and you no longer have to rely on new, market-untested solutions to do so. This fact, too, has helped make DevOps more popular than ever.

    How will the popularity of DevOps change from here? My guess is it will continue to rise as the market and DevOps tooling mature even more, and as DevOps continues to make its way into mainstream educational programs.

    — Chris Tozzi

  • JFrog swampUP: DevOps Culture Is a Powerful Force

    JFrog swampUP: DevOps Culture Is a Powerful Force

    The notion that culture is such an important part of DevOps and high-performing IT teams gets plenty of lip service, but not every organization really buys into it. In my years covering the DevOps space, I can count only a handful of companies that truly represent the epitome of “DevOps culture.” One of these companies is JFrog.

    Every time I have the chance to interact with “the Frogs” and their community, I am reminded of what a powerful force culture can be in forging success. At the recent swampUP user conference in San Francisco, the JFrog secret sauce was again on display. From the little things, such as designing and decorating the conference themselves, to the bigger things in terms of the theme of the sessions and activities, swampUP was a great and learning time for all. Our Digital Anarchist team was on hand and we did a bunch of videos that you can watch up on DigitalAnarchist.io. The videos are with speakers at the conference, attendees, JFrog employees and partners.

    One of my favorite videos from swampUP was the one I have embedded here. It is the three co-founders of JFrog—Yoav Landman, Fred Simon and Shlomi Ben Haim and I discussing business and what makes JFrog’s culture so special. Have a listen and maybe get some insight into making the culture of your own organization better.

    Also, if you are in Israel Sept. 24, check out Yalla DevOps, a first-time conference JFrog and others are producing that looks like it will be a great event. The Digital Anarchist team will be there covering with video (even broadcasting live), along with John Willis as a keynote speaker; Jayne Groll, my co-founder at DevOps Institute; and others.

    In the meantime, enjoy the video:

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for DevOps.com on Digital Anarchist, and we’re here in San Francisco at JFrog swampUP 2019. It’s been a great conference, and I’m really, really lucky and happy to be joined—I feel like I’m at a Beatles reunion, for some reason. I’ve got Ringo, Paul, John—

    Shlomi Ben Haim: Who’s John Lennon? I’m afraid. [Laughter]

    Shimel: – done. Anyway, but no, we’re not at a Beatles reunion, but we do have the three JFrog co-founders here with me. I’m gonna let them introduce themselves. We’re gonna go to the far right to Fred. Fred, go ahead.

    Fred Simon: Hi, I’m Fred Simon, co-founder and Chief Data Scientist today at JFrog and I’m really happy to be here. Thank you.

    Shimel: Thanks, Fred.

    Yoav Landman: Yoav Landman, CTO and co-founder of JFrog.

    Ben Haim: I’m Shlomi Ben Haim, CEO and co-founder of JFrog.

    Shimel: Three co-founders on one panel—there you go. So, guys, first of all, congratulations on another great event.

    Simon: Thank you.

    Shimel: You know, you know this, but you guys don’t know this—my wife wants to come work with you.

    Simon: [Laughter]

    Shimel: Because she loves the company and the culture and the buzz that she gets when she’s around the Frogs that, you know, when she grows up, she wants to come work at JFrog.

    But all kidding aside, it’s a tremendous—you can’t come to a JFrog event, whether it be swampUP or SwamPower or Meetup or whatever without kinda feeling the love, right? Feeling that culture. And it’s an interesting dynamic. Take it from me—I go to a lot of conferences, I deal with a lot of companies. They don’t all have that. They don’t have that culture.

    So, I wanted to talk a little bit about—look, 2009, you started Artifactory, right? What was the idea on the culture, here? How do you instill that culture—not in the community, right now. Let’s talk about the company, because every high performing team ranked culture as important. How do you instill that pride to be a Frog, we’re all in this together, we’re making the world a better place? Who wants to answer?

    Simon: You want to start? You started this mess! [Laughter]

    Yoav Landman: So, yeah, Artifactory started before JFrog. So, Artifactory was there to solve a real pain, and we were all developers, and it’s our second—except for Shlomi—it’s our second venture.

    So, I guess this idea of solving pains, being very connected to the community, to customers, speaking a lot with customers, getting feedback from every engineer and every employee in JFrog that comes and says that they think that something should work differently or that we should develop something that may contribute to more success of our product is something that is instilled into the culture of JFrog.

    Shimel: Excellent.

    Simon: Yeah, we got lucky that everybody else who is working at JFrog is working for someone like him. So, that’s scratching our own itch. So, at the end of the day, you are a developer at JFrog and you hear about a customer having an issue, you feel it, because this is your job. You’re writing code, you’re a developer, and you know that what you are doing is impacting people. And so, this strong care about the customer and the strong feedback of the culture was here right from the beginning.

    And then Shlomi one day decided, “Oh, that’s too big, too full of a culture. I’m gonna try to write it down.” [Laughter]

    Shimel: [Laughter] And Shlomi, with all due respect, you like to deflect and you let him talk, but you’re the CEO. At some point, the buck stops here, right? You know, it’s important to you, but how do you build this culture? How do you get this loyalty, this feeling of buy-in from people?

    Ben Haim: That’s, you know, I’m listening to the question and I’m  getting excited like it’s my first day at JFrog. I think culture matters. Everybody knows that, everybody said that. But it’s hard to practice. It’s hard to maintain it for 10 years. And this—this goes back 18 years. I think I’m with these guys before I got married, and what you see in JFrog is that when you have the right culture, it’s viral. But it’s not just an internal move, it’s also reflecting outside of the company.

    And you spoke about Artifactory and how it started, and when we started, the only thing that we had was the technology that we believed in and ourselves. And it’s very hard to start a company when nobody understands what you do on the technical level, nobody understands what’s the pain. There is no budget line for it. So, the only thing that you can fight with is your team.

    Shimel: Right.

    Ben Haim: And just yesterday, as we set up this amazing conference here, I saw more than 70 JFrog employees. You know that we do our conferences ourselves.

    Shimel: Right.

    Ben Haim: No producers, it’s just us. Our team built it for the community. And I saw them here walking, and it doesn’t matter whether it’s building Artifactory or Xray or JFrog Pipelines or JFrog Distribution or swampUP—same culture, same values, comes over and over again as our one very big advantage.

    Shimel: Absolutely. But now—so, that in and of itself is fantastic, right? But now, there’s a second key ingredient to the success. How do we take that culture that we built at JFrog and let the community, infect the community with it, right, to use a security term? How do we transform the community with that same—not transform, infuse that community with that same culture, with that same passion?

    Because that’s something that always, again, it screams, right? It’s easy to see. And building that kinda community is not easy, because at the end of the day, today’s software world with open source and everything else is community, right? It’s all about—so how, is that something that’s done on purpose? If so, how? What do we do?

    Landman: I can try and start.

    Shimel: Go ahead, Yoav.

    Landman: So, part of being driven by input is also being very direct. And it all comes down to people—at the end of the day, it’s all people. So, the way that we interact with the community, the way that we interact with customers is not very much different than the way we interact internally in JFrog.

    So, by bonding with people, by investing in clear and open discussions with no fluff, I think that drives results, at the end of the day.

    Shimel: Fred?

    Simon: First of all, I don’t think it’s intentional. I mean, it’s just the way we are and the way—and it’s pure and it’s just true, okay? We truly care about the suffering of our customer, and the customer feels it. So, once he feels it and then he’s part of it—and sometimes, it’s a little bit disturbing for the customer, because the customer feels like he’s gonna get more help and better integration with the JFrog community and with JFrog than with his peers inside the company, because of the [Laughter]—

    Shimel: Yeah, exactly.

    Simon:  – some cultural clash between the company and JFrog. And so, by, you know, not saying, “Okay, whenever a customer is telling you something, just be compassionate”—we never told our employees, “Please be compassionate about the customer.” This is just, this is who we are, and this is what the—and they see, and the customer feels it, and he sees the effort we put to make sure that… And it’s like here, the communication, also. The effort of communication, the effort of knowledge, knowledge transfer. We are not shy on transferring what we know, what we need, what we did. It’s just—yeah, I think truth and natural truth is a [Cross talk].

    Shimel: So, the word that comes to my mind is genuine, right? You can’t fake this. It has to be genuine. And if it’s not genuine, people see through it and it smells, right? So, I think that’s a key ingredient of that, for sure.

    And the transfer, too—I mean, I’ve done, I don’t know, maybe 10 interviews, 12 interviews, maybe more today, to a lot of customers. And that knowledge transfer and sharing in this kinda—it’s huge to them.

    So, now—so, we’ve got the culture to the community. Now, we’re gonna talk, Yoav, you said Artifactory existed before there was a JFrog, right? It’s 10 years, right? In technology terms, that’s like dog years, it’s 90 years, you know? It’s almost 100 years old already.

    Landman: Frog’s years. [Laughter]

    Shimel: Frog years. How do you—so, obviously, the Artifactory today is not Artifactory, what it was.

    Landman: For sure.

    Shimel: JFrog today is not what JFrog was. We mentioned something things—JFrog Pipelines, there was the Shippable acquisition, Xray came out about two years ago now, right? Two, three years ago—Xray. JFrog today—let’s talk about the technology, the tools, the solutions. What are you most—you’re CTO, Yoav. What are you most proud of with that?

    Landman: Artifactory was the centerpiece and it still is. It’s the place where you put—we call it the golden bits. It’s what you’re going to, at the end of the day, put in production, right? But the world has changed dramatically since Artifactory was written. It was just a very basic Maven remote proxy. And then other features came about, but the whole DevOps and the whole pipeline automation process that we’re seeing today within companies, it didn’t exist back then to the same level of automation.

    So, bringing in security into the pipeline is an integral part, with Shippable, making sure—we can maybe talk about this later—making sure that we can drive the pipeline, adding functionality to give you insights into the pipeline. These are all things that came along and are going to be injected into the pipeline from JFrog, from other companies, but this is the natural evolution. Artifactory is still the base of what you’re going to shift, but all the services around it is what makes JFrog a lot bigger and why it’s very different than what we started.

    Shimel: Fred, I wanna come to you in a second, but I have a follow up question for Yoav. So, Yoav, I think another great example is—so, in the last year, you announced you’re gonna start a repository for Go, yeah? And so, that’s an example of, you see what the community is doing. I spoke yesterday to a Microsoft fellow here who’s, like, their advocate for the Go community—so happy to be here because JFrog’s supporting him with that.

    Where does that come from? Like, where—the idea of saying, “Hey, we should do something for Go?”

    Landman: So, it comes from, I think, two angles. The first is purely technical, just being able to be there first. The other one is, I think, a little bit cultural, just being able to instill innovation into the company, even before the market adoption happens. And it kind of goes together. Both goals, they serve one another. So, we did the same, by the way, with Docker. With Docker, we had support for the Docker beta versions, even before Docker was a thing.

    And the same thing we wanted to do with Go, even when the standards were not that stable yet and we had to rewrite our implementation once the standards have stabilized. But yeah, this is the source of this motivation.

    Shimel: Fred, I wanna go to Liquid Software with you, right? So, it’s a book, we can probably have someone throw us a copy for a prop, if we can get Brian maybe get us a Liquid Software book over here, it’s right by Netta.

    But you’re one of the co-authors, Yoav, Baruch is one. So, that’s another concept, right? This whole concept of liquid software and what it is. Talk to us about that. What do we—where does that come from? How does that fit?

    Simon: Yeah, so the—by the way, where it goes to Go and all these kind of communities and things like that? The origin of manipulating software and trying to put software in production into an environment, we always try to manipulate it as boxes. A box where we put a bunch of software and we try to run it. And with the advent of releasing multiple ________ multiple versions and making all those services micro-micro-microservices—basically, the flow of those packages got higher and higher and the size of the packages got smaller and smaller.

    And so, instead of thinking about it in terms of ship management and supply chain management of shipping packages, it didn’t make sense any more. It was really, really a big burden on the tagging.

    And so, when you want to put a piece of software in production, you have the final run time, which is the software in the hands of your end user, the one that really, really wants to use it. And deploying software is actually easy. You just created a new piece of software, you just run it for the first time, and it’s quite easy, and then you run. What’s hard is to update it, okay? Deploying is easy, updating is hard. And the only way to update it is to get the new version. And if you keep thinking about it in terms of blocks, you’re stuck. You need to think about it in terms of pipes and liquid and this is the liquid software. Is that, as soon as you create a run time that can receive software, you need to think about all the pipes that you need to plug to get the liquid to it and to update it continuously.

    And it changed all the way to the developer. This is—it starts from the pressure from the end users from, like you said, your wife, your daughter or whatever that wants to get the latest software all the time without any, and it put the pressure all the way to the developer. And what’s funny in our environment is that it’s hard for a developer to do it correctly, and a lot of times they said, because they are used to it, when they interact with technology, actually, the developers are a lot more, first, reluctant to update software. If you see all the developers and their phones, iOS and Android, they have the most, the oldest version, the one that doesn’t update. [Laughter] And they want to control [Cross talk].

    Shimel: It’s the mechanic’s car.

    Simon: Yes, exactly. [Laughter]

    Shimel: Never drive the mechanic’s car.

    Simon: And so, for them, it’s not that complicated to do a complicated update. So, it really comes from the pressure from the market, and life is ________ is a really good, it’s life pushing it and so liquid software is gonna happen whenever it’s gonna happen.

    But the change that we need to push is to put the tools and the mechanism and the practices into the hands of the developer. Because it’s not that hard. It’s hard, it’s some work and stuff, but it’s not as impossible as the community of developers think.

    So, it’s a book, I highly recommend it.

    Shimel: Here’s the book. We’ve got the book, thanks to the folks offstage.

    Simon: But it kind of tried to remove this fear from the developer community of writing liquid software. It’s possible.

    Ben Haim: And, you know, Alan, I think that the experience of being in a very successful company for over eight years and not being able to explain what is it that we are doing, why it’s more than just managing your binaries, why it’s more than just providing you with a better repository. And when Fred came up with this phrase, liquid software, it was one presentation that everybody in JFrog understood and immediately aligned to it. Because this is actually what we believe in. And when you go and raise your Series D and you say—

    Shimel: Which was this year.

    Ben Haim: – this last year, last October, seven months ago. And when we said—nine months ago.

    Shimel: Yeah. [Laughter]

    Ben Haim: When we said, “We are the liquid software company,” we had all kinds of eyebrows moving, and people are asking us more and more about that, because they start to understand that this is beyond just the vision of JFrog. This is where the world is going. We are just one of the enablers of the liquid software world.

    Shimel: Absolutely. So, first of all, I still can’t explain to my family what I do for a living, but that’s another story.

    Ben Haim: [Laughter] The story of my life.

    Shimel: Yeah. But, you know, in some ways, this is also the story of JFrog, because 9 years ago, 10 years ago, Artifactory, I would’ve told you, “Liquid software? What is it? What do you”—stop.

    Ben Haim: Yeah. Stop with the drugs.

    Shimel: Right. But yet, the kernel of what is liquid software according to you was there in Artifactory 10, 11 years ago. Yeah.

    Landman: The essence is.

    Shimel: Yeah. and so, it’s—you know, I learned once, what we do in technology is, 99 percent of the time evolutionary, not revolutionary. And so, this is the revolution of it.

    So, I’d like to, now, if we can—and Liquid Software is available, you can get it. The book’s on Amazon. I think it’s on—

    Simon: Audible. It’s Audible, also.

    Shimel: Yep. We had it on DevOps.com on a link, too, at one time. We probably still do, obviously.

    But I wanna now turn a little bit, you mentioned D round was a couple dollars, 165,000,000—that’s not even shekels, dollars.

    Ben Haim: [Laughter] It sounds better in shekels, by the way.

    Shimel: Yeah. It’s like the speed of light. But you know what, when you raised—Yoav and I were talking earlier—you raise that kind of money, with a lot of money comes a lot of responsibility, a lot of expectations. Where does JFrog go from here, right, and how do you chart that course, right? As a CEO, CTO, developer advocate, technology—how do we, where do you, where do you go? How do you know where to go, right? You’ve got tremendous resources now at your disposal, probably more than you might have dreamed you’d have to do.

    Where do we go and how do chart that course?

    Ben Haim:  So, I’ll try to answer that from a high level and then, of course, Fred and Yoav can take it to the technology solution. I think that JFrog has done something really big. And when you see what happened in the world, it’s beyond the developer. It’s beyond the people who are actually using our solution. It’s the destination that was changed. And what people expect to have is a fast and fluid software update. And if JFrog, with 5,000 customers today and growing fast, can be the company that powers this need, then I think we have a very big story.

    So, when we raised our money—you know, when you raise such an amount with such an evaluation, you also understand that the dream about M&A and exit is kind of pushed away and the list of acquired got changed to maybe three or four companies.

    Shimel: Very small—a handful.

    Ben Haim: So, you have to go and ask your wife about it, because this is 10 years, together 30 years of investment that our family was part of this journey. And I asked Donna, my wife, and I said, “Donna, you understand that there will be no exit soon. We have to go all the way—all the way towards it.” And the answer that I got is that, “If this is really what you say it is, if it’s really changing the world, if it’s really about electricity and water and aircraft and cars and everything you do, I’m so excited about it, and I’m not even a technologist, then you guys should go after it.”

    So, I think we have made the right choice, and you’re right, there is a lot of responsibility here. It’s a responsibility not just to our VCs, but also to our employees that trust us and follow us, and also to our customers—

    Shimel: And the community.

    Ben Haim: – that comes and uses it and over and over again, we are growing at 150 new logos per month—new logos per month. These are people that adopt this solution and say, “This is what we are going to do in the next 10 to 20 years. We are making software liquid.”

    Landman: So, JFrog for a long time is not just the sum of the founders, it’s much, much bigger than that, and we have wonderful people in the company that leaped forward with JFrog and take the company forward, basically, for us and for the other investors.

    One thing that you have to understand is that, today, JFrog is taking the responsibility of serving huge organizations and our end customers are also sharing this responsibility of serving the automation for huge organizations, and the automation patterns that we are seeing, they are not constant. They are changing and they keep evolving over time.

    So, this is kind of great, an ever growing challenge for us to develop a new set of tools, a new set of solutions, new pains to cure. To tell you that we exactly know what the next pains are going to be—we don’t. If we would, it would probably be too boring to continue going, like Shlomi said. But this is basically what drives us and keeps us committed to this responsibility.

    Simon: Yeah, still a ton of work to do. I mean, the liquid software vision, there’s still a lot, a lot, a lot to do. And like Yoav said, the responsibility that we have as being a critical piece of keeping those pipes, making sure they don’t leak, making sure nobody’s injecting stuff into it. And making it happen and making the water system trusted and the software delivery trusted is a huge amount of work, responsibility, and systems that we have to create on the way, we have to build, and we have to scale to worldwide—really, worldwide impact and environment.

    So, you can say that 160 is a lot of money, and when I see the amount of things that need to be done, maybe not. [Laughter]

    Shimel: Yeah. Well, there’s always more out there. Guys, we’re way over time, but I wanted to end it with this. I sold my first company in 1997, and I sold it to, well, a guy named Brad Feld who’s a pretty well-known venture capitalist himself. But his mentor was an older Jewish man, Len Fassler—a little older, he was like my grandpa. I couldn’t negotiate against him.

    Ben Haim: [Laughter] No, it’s impossible.

    Shimel: It was like negotiating with your grandpa. But Len had good—he did several billion dollar companies, rollups and good stuff. And I then worked for him and we did 30 acquisitions in 36 months, and we wound up taking the company public in the dot cot days.

    And one of the things he always said to every founding group, whether we bought the company or not, was, “Any time you can build a company that someone’s willing to reach into their pocket to invest in and write you a check, you have a lot to be proud of,” right? To write a check for $165,00,000.00—that’s plenty to be proud of. But even beyond the money, when you look out at swampUP, when you look out at all those Frogs’ faces, you guys have a lot to be proud of, so congratulations.

    Ben Haim: Thank you very much.

    Shimel: Thanks for joining us.

    Ben Haim: Thank you.

    Shimel: And continued success. Hey, we’re gonna wrap it here in San Francisco from JFrog swampUP, this is Alan Shimel for DevOps.com and the Digital Anarchist.

    — Alan Shimel

  • Doing DevOps in an Interconnected World

    Doing DevOps in an Interconnected World

    Doing DevOps would be simple if you had total control over the tools, code and infrastructure that your company used. But the fact is, you don’t. Instead, we live in a world where most CI/CD chains connect in some way to third-party resources or processes.

    In other words, doing DevOps effectively means integrating with entities that are external to your organization. Here’s a look at what this entails in practice and why it’s so important.

    The Interconnected World of DevOps

    Conversations about DevOps often assume that all DevOps processes happen internally. In reality, many software delivery pipelines depend on third-party resources and services. Consider the following examples of ways companies could make their software delivery chains dependent in part upon third-party agendas:

    • They integrate open source code into their codebases and therefore depend on an open source community to write some of their code.
    • They maintain relationships with partners and need to be sure their release schedules and toolchains are compatible with their partners’ needs.
    • They need to make sure the applications they deliver work on different operating systems, browsers and hardware devices that are controlled by third parties.
    • They are subject to regulatory rules handed down by third parties and must ensure their delivery chains meet those regulatory requirements.
    • Their applications depend on APIs that are designed and updated by third parties.

    In these ways and more, the CI/CD pipelines organizations build to do DevOps need to be able to integrate with, and adapt to, decisions made by third parties. If they don’t, the organizations risk problems such as broken code, the loss of partners and regulatory compliance issues.

    Succeeding at Interconnected DevOps

    This is why it’s critical to design CI/CD pipelines and other DevOps processes in ways that make them mesh with third-party resources and services. In practice, this means:

    • Adopting tools that are flexible and have broad coverage. You don’t want to tell a partner you can no longer work with their code because your CI server doesn’t support their new programming language.
    • Use branching in the CI/CD process. Multiple branches give you more flexibility to support different target environments. They also help you react to sudden changes made by third parties without having to overhaul your entire CI/CD process.
    • Make sure your collaboration and communication channels integrate with those of third parties on whom you depend. If you use open source code in your application, for example, add the open source project’s security announcements to your Slack channel so you’ll be notified right away when a vulnerability arises.
    • Choose your integrations wisely. Just because you can integrate a third-party API into your application, for example, doesn’t mean you should. Too many dependencies put the efficiency of your CI/CD pipeline at risk.

    No matter the details of your CI/CD chain, the most important thing is simply to recognize that we live in a very interconnected world and most organizations don’t have total control over their software delivery processes. That’s just a fact of modern DevOps. But with the right planning and strategies, you can ensure that third-party dependencies add value to your software delivery pipeline rather than creating unnecessary risk and overhead.

    — Chris Tozzi

  • IBM Closes $34B Red Hat Acquisition

    IBM Closes $34B Red Hat Acquisition

    Following the official closing of IBM’s $34 billion acquisition of Red Hat today, leaders from both companies reiterated Red Hat will continue to operate independently of IBM but will leverage IBM resources to advance the hybrid cloud computing ambitions of the newly combined entity.

    Arvind Krishna, senior vice president for cloud and cognitive software at IBM, said IBM and Red Hat together will be in a better position to address what he described as Chapter Two of a continuing cloud journey. With 80% of applications still running in on-premises IT environments some 10 years after the arrival of public clouds, it’s apparent hybrid cloud computing will become the dominant form of IT, he said.

    Red Hat will play a critical role in helping customers achieve that goal using a common operating model based on distributions of Linux and Kubernetes container orchestration software, Krishna said. However, he added, IBM sees no need to rationalize its current middleware software portfolio, which often addresses use cases that Red Hat doesn’t.

    Paul Cormier, executive vice president and president for products and technologies for Red Hat, said Red Hat will continue to invest in products and projects independently of IBM. As such, Red Hat does not expect its relationship with its partners that compete directly with IBM to change substantially, he said. At the same time, he stressed that working more closely with IBM will accelerate a 100% open source approach to hybrid cloud computing that otherwise would have taken Red Hat “many years” to execute on its own. That hybrid cloud computing strategy, in contrast to rivals, will span virtual machines, bare-metal servers and public clouds, Cormier said.

    Other than introducing Red Hat to a potentially larger customer base, it’s not quite clear how being a unit of IBM accelerates the Red Hat strategy. Red Hat and IBM sales teams, for example, will have no incentives to cross-sell offerings and Red Hat will continue to promote its brand independently of IBM, in much the same way VMware operates independently of the rest of Dell Technologies. Both Red Hat and IBM also stressed there is no plan to impose an IBM culture on Red Hat or lay off any personnel. There is a consensus that open source software will play a role in enabling hybrid cloud computing that should generate opportunities for IBM to generate more professional services revenue.

    Longer-term, there’s clearly an opportunity for both Red Hat and IBM to promote the adoption of a common set of best DevOps practices across a hybrid cloud computing environment. Many organizations, however, are already moving to extend those best practices across all the platforms that make up very diverse IT environments.

    For now at least, organizations that have already committed to Red Hat appear to be lending their continued support. Red Hat’s fiscal year 2019 revenue was $3.4 billion, up 15% year over year. Fiscal first-quarter 2020 revenue was $934 million, up 15% year over year. Services revenue for Red Hat also grew 17%. Precisely how IBM and Red Hat intend to unlock the value of this merger beyond the momentum Red Hat already enjoys, however, remains a bit of a mystery.

    — Mike Vizard

  • DevSecOps Survey Finds Failure to Communicate

    DevSecOps Survey Finds Failure to Communicate

    While it’s generally agreed that shifting more cybersecurity responsibility onto the shoulders of developers is a good idea, a failure to communicate across application development and cybersecurity teams has contributed to little progress in achieving DevSecOps.

    A survey of 1,310 IT decision-makers conducted by the market research firm Vanson Bourne on behalf of Trend Micro finds that while nearly three-quarters of respondents (74%) said integrating developer, IT operations and cybersecurity processes has become more important over the past year, more than one-third (34%) said these silos are making it more difficult to create a DevOps culture in the organization. A full 89% said software development and IT security teams needed to be in closer contact, while 77% said the same for developers, security and operations.

    Greg Young, vice president of cybersecurity for Trend Micro, said the two biggest challenges in achieving DevSecOps historically are the lack of trust between developers and cybersecurity professionals and a lack of tooling to foster collaboration and communication across teams.

    The rift between developers and cybersecurity is well-known: Application developers have been known to give short shrift to cybersecurity guidelines to make a deadline, only to have that application breached in a production environment. However, developers can counter that cybersecurity professionals can slow things down too much, in the name of being overly cautious.

    Young said organizations need to find tools that make it easier for those two teams to establish trust within the context of an integrated DevSecOps process. Rather than just relegating cybersecurity teams to defining policies, cybersecurity professionals need to find a way to provide input during all stages of the application development process without compromising the overall agility of the development team, he said.

    In fact, survey respondents identified fostering greater integration between teams (61%), setting common goals (58%) and sharing learning experiences across teams (50%) as the best ways to achieve DevSecOps. The trouble is, 78% of respondents said their organization needs to improve in all these areas.

    Unfortunately, nearly half of respondents (46%) said they have only partially developed their DevOps strategy, with only a third of respondents (33%) saying DevOps today is a shared responsibility between software development and IT operations.

    Regardless of how organizations achieve DevSecOps, the one certain thing is most organizations have no alternative. The rate at which applications are being developed today generally exceeds the ability of short-handed cybersecurity teams to keep pace. The only way to make sure applications are more secure than they have been historically is to make implementing security controls part of the application quality assurance process. That said, cybersecurity teams most likely will take a “trust, but verify” attitude toward developers to ensure the right controls have been put in place.

    Of course, none of this is going to happen of its own accord. Senior leaders need to make DevSecOps best practices a requirement. Otherwise, DevSecOps will always remain one of those many aspirational IT goals that go unfulfilled.

    — Mike Vizard

  • How DevOps Training and Certification Benefits the Team

    How DevOps Training and Certification Benefits the Team

    Cisco Systems recently announced sweeping changes to its training and certification programs to increase the real-world value of both. Cisco’s move demonstrates a trend by organizations that provide training and certification to place more value on the practical aspects of educating technology professionals—which, in turn, should have a major impact on those looking to build DevOps teams.

    “Advances in network technologies have enabled new applications and business models—converged IP networks enabled voice over IP, 3G networks enabled mobile applications and 4G networks enabled mobile video,” said Susie Wee, senior vice president and CTO of DevNet at Cisco Systems. “DevOps has become a key factor for bringing those new networked applications to life. Training and certifications for network professionals and software developers have become a must. The goal here is to bring enhanced software skills to networking, enabling application developers to write applications that leverage the full capabilities of the network.”

    Cisco’s realization that real-world knowledge brings demonstrable value to businesses has culminated in new DevNet Certifications, which are designed to demonstrate an individual’s ability to bring software skills to evolving network technologies. “The only way to fully leverage the capabilities of the network is to build DevOps teams with both networking and software skills that can address the intricacies of both software-defined networking and physical networking solutions,” Wee added.

    Cisco is not the only company pursuing a change in training and certification processes. Industry group CompTIA recently revamped its certification programs. For example, the latest version of the CompTIA Linux+ exam has been redesigned to validate the competencies and skills required of early career IT professionals supporting Linux systems.

    “For certifications to have real value today, people must immerse themselves in the technology,” noted James Stanger, CompTIA chief technology evangelist. “The new Linux + certification uses performance-based testing that presents candidates with real-world scenarios, meaning that achieving certification demonstrates the ability to function in the real world.”

    CompTIA may very well be one of the leaders in the movement to bring real-world relevance to the certification process. The company has been using performance-based testing and has been embracing certification pathways to build teams. “For DevOps teams, critical skills, including project management, both agile and waterfall, are important. Developers will need to know the operating systems they are developing in, so they’ll need to understand Windows and Linux,” Stanger said. “The idea is that for DevOps, you need to get deep into the guts of operating systems and understand them well. You can specialize in one area, but you’ll also need to understand databases, relational databases and object-oriented databases.”

    Cisco also understands the importance of educating DevOps professionals. “Our new Cisco Certifications, with new DevNet Certifications, are designed for training and certifying network professionals and software developers, so they can bring software skills to networking,” Wee noted. “This new education process teaches application developers how to write applications that leverage the full capabilities of the network, and it helps build IT teams with network skills and expertise and software skills and expertise so they can leverage the full capabilities of the network, helping to support the DevOps process.”

    Cisco is also investing in the idea of building a community in the form of the company’s DevNet offering. DevNet was created some five years ago to help network engineers and application developers take full advantage of the revolutionary changes shaping the industry. The company is now focusing its efforts on what it sees as its customers’ biggest problem—network automation—and has created the DevNet Automation Exchange, a community-based developer center where networkers and developers can learn to “walk, run and fly” with network automation using Cisco’s products and the full capabilities of the new network.

    According to Wee, those three processes can be broken down into:

    • Walk: Get visibility and insights into their networks in a read-only way. This enables use cases such as gathering telemetry and insights from running networks and performing audits to ensure the ongoing security of the network.
    • Run: Activate policy and intent across different network domains. This enables use cases such as providing self-service network operations that comply with security policies and operational guidelines.
    • Fly: Proactively manage applications, users and devices with DevOps workflows. This enables use cases such as deploying applications in continuous integration and continuous delivery (CI/CD) pipelines while configuring the network in accordance with new application policies.

    Wee noted Automation Exchange has been seeded with more than 50 code repositories, many contributed by Cisco’s engineering teams and SEs. Now, she said, the company is inviting DevNet community members to submit code that solves their use cases.

    Updated certification and training resources from the likes of Cisco and CompTIA will go a long way to helping build DevOps teams that can hit the ground running.

    — Frank Ohlhorst

  • AI for IT Operations: All It’s Cracked Up To Be?

    AI for IT Operations: All It’s Cracked Up To Be?

    Artificial intelligence for IT operations (AIOps) is becoming a critical tool for organizations attempting to bring automation quickly to network management and IT problem resolution. However, many organizations are still unsure how to deploy AIOps for the most value and to net the full, promised results. Perhaps the challenges come from not looking beyond data silos, or perhaps the problems can be attributed to a lack of understanding AIOps’s full potential in the enterprise.

    Enzo Signore, chief marketing officer at FixStream, lends credence to the problem of siloed information. “Despite continued investments in system resources, IT cannot holistically see what’s in their physical and virtual infrastructure,” he said. “And without a clear view of the entire IT environment and the ability to make sense of the mountain of data being served up by various system tools, Ops teams can’t figure out what’s wrong or how to fix it.”

    In essence, for AIOps to be successful, IT must be able to access that siloed data and then be able to process that data to derive actionable insights, exactly what AIOps is meant to do. Yet, complexity still seems to be one of the major challenges of bringing a holistic approach to managing networks and resolving problems. 

    “IT teams are bogged down by the sheer complexity of today’s hybrid, dynamic IT environments,” Signore noted. “Along with steep learning curves and lightning-fast changes to new technology, IT departments must cope with soaring consumer expectations, supporting legacy systems, lack of skilled talent, disparate tool sets and opaque physical and virtual IT infrastructures. These factors complicate IT staff’s ability to oversee operations and optimize system performance.”

    Naturally, companies such as FixStream have a major stake in the AIOps game; the company offers numerous AI solutions that promise to modernize IT operations and bring AI into the realm of IT operations. However, understanding what AIOps is all about is one of the first hurdles to overcome when contemplating the technology. Gartner defines AIOps as platforms that enhance IT operations through greater insights by combining big data, machine learning and visualization. “IT leaders should initiate AIOps deployment to refine performance analysis today, and as an augment to IT service management and automation within the next two to five years,” advised Pankaj Prasad, senior principal analyst at Gartner.

    Gartner defined some best practices that businesses should adopt, which include: 

    • Deploy AIOps by adopting an incremental approach that starts with historical data and progress to the use of streaming data, aligned with a continuously improving IT operations maturity.
    • Select platforms that enable comprehensive insight into past and present states of IT systems by identifying AIOps platforms that are capable of ingesting and providing access to text and metric data.
    • Deepen the IT operations team’s analytical skills by selecting tools that support the ability to incrementally deploy the four phases of IT operations-oriented machine learning—descriptive, diagnostic, proactive capabilities and root cause analysis, to help avoid high-severity outages.

    Best practices aside, FixStream’s Signore opined that there are some other challenges that must be addressed. “Without the foundational capabilities of accurate discovery, contextualization and full-stack correlation, AIOps can become severely limited,” he said. “The lack of those features have become the big elephant in the room that everyone is not addressing, and it’s holding back the advancement of AIOps and machine learning for many companies.”

    Simply put, when AIOps is not fully deployed, important insights may go unnoticed and leads to data remaining in silos. “Companies are getting all this data, but it’s not being properly processed and correlated, and it’s going to waste,” he said.

    It is those types of deployment issues that are lending credence to AIOps not being as effective as promised. “AIOps is a multi-layered platform whose capabilities should include efficient data collection at big data scale, correlation across the collected data, machine learning, analytics and visualization,” said Bishnu Nayak, FixStream CTO.

    Businesses discouraged by the initial ROI of AIOps should take a long, hard look at their implementation strategy and take into consideration what their data sources are and how they are applying analytics, Nayak said. “Done right, an AIOps implementation can lead to a decreased mean time to remediation and better proactive problem-solving. By increasing system availability and responsiveness, AIOps can enhance your digital business operations and improve profitability.”

    — Frank Ohlhorst

  • 5 Ways DevSecOps Can Manage Software Supply Chains

    5 Ways DevSecOps Can Manage Software Supply Chains

    The unbridled use of open source components within the software supply chain is on a major uptick, according to new research. Even as this surge in open source dependencies fuels faster innovation, the study shows that it comes with high cybersecurity costs, as the number of breaches related to these components is similarly on the rise.

    However, the numbers also indicate there are some clear practices used by the best DevSecOps teams to minimize the risk while maximizing the speed and agility that third-party components offer.

    Sonatype and research partners from IT Revolution and Galois made a thorough analysis of download patterns, software component makeup and DevSecOps behaviors around open source components and third-party libraries for the “2019 State of the Software Supply Chain Report.” Their analysis found that the rate of open source component releases has picked up by 75% in the last two years and that download requests from teams using these components have risen 68% year over year.

    Most tellingly, the study showed that among modern applications today, 85% of the average code base is comprised of open source componentry. Not only are the majority of applications using open source components and libraries, but also they depend on them heavily.

    “The practice of assembling open source component releases into the form of an application screams of efficiency. Developers no longer need to code every line from scratch,” according to the report. “Developers can download component releases in seconds that deliver new capabilities, built by experts outside of their organizations who make their code freely available to others.”

    Perhaps not coincidentally, the study noted a parallel rise in breaches associated with open source component use. Last year 1 in 4 organizations suspected or verified they experienced a breach related to open source components in the last 12 months. That’s a slight improvement over last year’s stats, which had it pinned at 1 in 3 organizations. But since 2014, that rate of breaches has risen by 71%.

    The trouble is, many of the components developers download and integrate into their code are full of dangerous vulnerabilities. For example, just over half of all JavaScript package downloads contain known vulnerabilities, with 1 in 3 rated as high vulnerabilities. One in 10 of those flaws were rated as critical.

    The point the report hammered home is that not all components are created equally. There exists a certain class of well-run open source projects that release updates more frequently, update problematic vulnerabilities faster and remediate flaws more quickly. It is up to DevSecOps teams to systematically manage components, so they leverage more of these high-quality open source projects and try to avoid the riskier open source dependencies.

    “Management of software supply chains is not simply ensuring quality at velocity. Our supply chains are being attacked by adversaries in new and creative ways,” according to the report. It found that organizations that actively manage their supply chains are able to reduce the proportion of vulnerable components by 55% compared to those who do not.

    The report found several software supply chain practices contributed to this reduction of risk, with the following five standing out as the most impactful:

    Develop a governance program: Foundational to this is having some sort of open source governance or standards policies in place, according to the report, which noted that among the best DevSecOps organizations at managing risky components, nearly 3 in 4 have such policies in place.

    Have a process for evaluating and adding new components: As a part of that open source policy, the best teams have standardized processes for how developers add new open source components. This includes how these components are evaluated, approved, standardized and so on. The exemplary organizations are 11 times more likely to use this kind of process for new dependencies.

    Proactively remove problematic components: New vulnerabilities are discovered every day, so simply evaluating a dependency upon its first inclusion in an application can only take an organization so far. The best organizations also take the initiative to look for potential sources of open source vulnerabilities in existing code. That includes proactively seeking out and removing known vulnerable dependencies, as well as reducing the attack surface of the code by eliminating open source dependencies that aren’t being used. The best organizations are 9.3 times more likely to do so.

    Aim to always use the latest versions of components: It should go without saying that the latest version of any given component has the least vulnerabilities. The report showed that component releases that are 3 years or older have a 65% higher defect rate compared to newer components. Exemplary organizations strive to use the newest updates of all of their open source components and are 6.2 times more likely to do so than other organizations. That doesn’t happen accidentally—these teams are 10 times more likely to schedule update dependencies as part of the daily work of DevSecOps teams.

    Use Enforcement Automation: Just having a policy in place is not enough—organizations need to enforce the open source standards to reduce risk meaningfully. The study showed that DevOps practices combined with automated enforcement of policies increase developer adherence to standards by 150%. The exemplary teams with the lowest open source defect rates are 12 times more likely to have automated tools to track, manage and/or ensure policy compliance of open source dependencies.

    All of these best practices add up to less risk from components, as well as less pain for DevSecOps teams, who are three times less likely to consider the process of updating components as painful.

    — Ericka Chickowski