Category: Blogs

  • In Service Management, AI Is Still Aspirational

    In Service Management, AI Is Still Aspirational

    Artificial intelligence (AI) has become a matured concept, the excitement of which is bearing results for a number of sectors and it holds a good deal of promise for a bright future. AI is the act of making possible for machines to learn from “experience” while adjusting to new input and stimuli so they can perform human-like tasks, ultimately leading for more complete automation in many traditionally man-powered processes. Computers can be “trained” to accomplish specific tasks, process data and recognize patterns in the data.

    While the use of service management solutions escalates, so do the potential uses for AI approaches in the sector. Because of this, there are advantages to discuss as well as examples of how AI can help to improve the service management operations of your organizations. But AI is a broad and far-reaching concept that’s often misunderstood and difficult for those that don’t work with the technology to understand its full capabilities.

    Is AI All Hype or Is It Actually Helpful?

    Based on the 2018 Interop ITX AI: Hype or Substance report, in a survey of 182 technology professionals, almost two-thirds of these respondents’ organizations are currently working on AI products or evaluating the technology. However, only 12 percent are using AI in production today. For those who responded during 2018, 6 percent of those using the technology said their budgets for it were set to decrease. The outcome, per the report, is that AI interest is high, but the ability to execute is low.

    Are AI Expectations Too High?

    The return on investment of AI is not clear and nearly one-third of organizations say they lack the budget they need to move forward, Information Week reports. Additionally, despite the desire for AI initiatives to reduce manual processes, these tasks must still be carried out by talent in the organization. A lack of expertise is often cited as a barrier to AI initiatives because there is not enough expertise to push the efforts forward. Alternatively, of those surveyed, more than a quarter said they haven’t defined a business case yet and close to half said they “have no idea” what effect AI may have on their businesses.

    Part of the problem with AI is the broad nature of its concept. Much of what we thought we knew AI was is now standard practice. For example, early AI efforts like IBM’s chess computer, Deep Blue, is part of our computing world now. Currently, demand or desire for AI capabilities is still aspirational, but usually is conflated with “machine learning”—where a computer or programming provides examples for how a machine can “learn” how to complete said task. Machine learning has huge potential to help societies automate previously manual systems. Through this, new economies will be developed and work (and workers) will evolve. Certain jobs, eventually, will become minimized and even discontinued in favor of new process and “ways of doing things.”

    We have seen these cycles before. In the United States, from a macro level, there’s been a major shift from a farming/agricultural society to one of more urban-based manufacturing/industry; into the post-industrial; then global-focused; and web-connected economies. These can be drilled down further but the point is made—major variations in our economies and jobs have taken place in a relatively short period of time. Based on these changes, we’ve had to change; jobs and workers have had to change. Machine learning is another disruptor for the new global economy that will force change.

    Hyped Up

    The hype of machine learning—a technology with huge potential—may not actually be overhyped. That said, how will this technology actually impact our everyday lives, and will machine learning change the work we do in service management? Perhaps we’re now starting to get a better idea of what those realities may look like.

    As far back as 2017, Gartner said that machine learning hype peaked, but expectations remain high. For service managers, there’s going to be more than intelligent chatbots to worry about but for now, much of the anticipation likely will continue. Machine learning can be a beneficial tool for identifying trends and changes in trends. In service management, machine learning means quick responses can help recognize when there is an above average number of calls logged, for example, or an unusual number of calls within one category, which can be acted upon.

    For most pressing trends—a specific cloud service that may no longer be available, for example—meaning machine learning-driven technology can recognize this breakdown by sending a signal to a specialized member of the service team, who can then react to this issue. Long-term problems also can be addressed through machine learning technology, spotting urgent disruptions. This may be particularly important during problem management. A labor-intensive process, machine learning has the capability of being able to recognize patterns in these calls, making the discovery of structural problems much easier.

    Misconceptions About Machine Learning

    Misconception surrounding AI and machine learning is rampant from replacing most of our jobs and replacing massive amounts of humans in the workforce to their surpassing our pre-programmed uses for the technology, in which the machines rise up and enslave us all. The more realistic version of things is a bit more benign. The most common current misconception is that chatbots and virtual assistants will make service desk employees redundant in short order. But this won’t likely be the case for the better part of a half decade or more because the technology isn’t sophisticated enough. Most chatbots are pretty expensive and don’t always work well.

    For now, machine learning will likely only help “answer” direct questions more quickly. More complex issues must still be handled by people. The realized benefit here is that because machine learning technology can help solve the easiest questions service desks face, there’s more time for service desk team members to solve the more complex calls.

    Someday Soon …

    Soon, machine learning technology will become better at finding the right information and offering solutions that actually benefit humans. Then, service desk employees will be able to focus more on the overall customer experience in ways that machine learning likely never could.

    While AI is maturing, excitement surrounding this experiment may need to be tempered for a bit. The technology is in the act of making possible for machines to learn from “experience” while adjusting to new input and stimuli so they can perform human-like tasks, but more complete automation in many traditionally man-powered processes is still needed.

    — Nancy Van Elsacker Louisnord

  • Why You Need DevOps and the Cloud

    Why You Need DevOps and the Cloud

    DevOps and the cloud are not only two of today’s biggest tech trends, but are inextricably linked. Research from DORA’s 2018 Accelerate State of DevOps Report and Redgate’s 2019 State of Database DevOps Report outline a clear correlation between cloud and DevOps adoption, with the two working together to contribute to greater business success.

    For example, in the DORA report, those companies that met all essential cloud characteristics were 23 times more likely to be in the elite group when it came to DevOps performance. Similarly, Redgate found that 43 percent of organizations that have adopted DevOps have server estates that are all or mostly cloud-based. This compares to just 12 percent of organizations that have not yet adopted DevOps or have no plans to.

    Looking into the link in more detail, research shows that there are four common factors that underpin DevOps and the cloud:

    Cultural Openness to Transformation

    Adopting DevOps is not just a technical or process change, but one that requires a certain type of culture to be in place. The renowned sociologist Ron Westrum famously categorized business cultures into three groups in his seminal paper A Typology of Organizational Cultures:

    • Pathological: Power-oriented, with low co-operation, a culture of shooting messengers bearing bad news and the crushing of novelty.
    • Bureaucratic: Rule-oriented, with limited co-operation, a neglect of messengers and a suspicion of novelty.
    • Generative: Performance-oriented, with high cooperation, messengers encouraged and a focus on learning from mistakes and embracing novelty.

    It’s no coincidence that DevOps and cloud adoption both thrive best in a generative culture that is open to innovation and is focused on collaboration and continual learning and improvement. In fact, the DORA research found that a generative culture correlates with elite performance when it comes to software delivery, and that this group is 1.8 times more likely to recommend their team as a great place to work.

    Building this open culture requires team members to feel safe about taking risks, rather than continually covering their backs, as well as good communication from leaders. This psychological safety underpins the continuous improvement mantra of DevOps and the innovation that the cloud delivers.

    The Importance of the Cloud to Enabling Faster Software Delivery

    As the DORA report found, cloud users are more likely to be elite performers when it comes to DevOps. But the research also highlights that there is a lot of confusion about what “moving to the cloud” actually entails. The National Institute of Standards and Technology (NIST) defines cloud computing as having five essential characteristics:

    • On-demand self-service
    • Broad network access
    • Resource pooling
    • Rapid elasticity
    • Measured service

    Just 22 percent of DORA respondents agreed or strongly agreed that they met all of these criteria. Those that did were 23 times more likely to be elite performers when it came to software delivery. This shows that simply moving to the cloud alone doesn’t lead to DevOps success—the switch needs to be implemented professionally, in a planned way. This goes back to culture—the same openness to innovation has to underpin both, DevOps and the cloud, to realize their full benefits.

    Breaking Down Barriers

    One of the key points of a generative culture is openness to collaboration, which is clearly essential to DevOps and, in particular, incorporating the database into DevOps flows. In the past silos, rivalries and even animosity built up between application developers and database administrators (DBAs). In many ways this isn’t surprising—developers are focused on getting new code out of the door, while DBAs are seen as protecting data and databases and ensuring uptime.

    However, for DevOps and the cloud to succeed, teams need to take a holistic view that breaks down team barriers. Redgate’s research shows that this is now happening, starting with the working relationship. Sixty two percent of respondents characterized the relationship between DBAs and developers as either good or great, up from 58 percent in previous years. This is heartening—only 13 percent said the relationship was poor with DBAs completely siloed, unaware of what’s happening in development, and deploying database changes to production in isolation.

    In teams that have adopted DevOps across all projects, the great and good collaboration rises to 76 percent, with 41 percent stating great collaboration—almost double the overall average.

    This collaboration is also reflected in daily activities. For example, over three-quarters (77 percent) of application developers are also responsible for database development and building database deployment scripts. In 47 percent of companies, developers are also responsible for the deployment of database changes to production.

    Putting in Place the Right Tools

    The collaboration behind successful DevOps and cloud adoption requires companies to introduce common practices and common tools across the entire process. This is reflected in figures from the Redgate research, with a growing adoption of the same tools within application and database development. Version control is now used by 83 percent of respondents for application development, and 55 percent for database development, rising steadily from 81 percent and 53 percent respectively in 2018. Particularly encouraging is the significant uptake in continuous integration—a cornerstone of DevOps—which is now used by 53 percent of respondents for application development and 27 percent for database development, up from 40 percent and 21 percent in 2018.

    All of this is leading to increased usage of third-party tools across DevOps processes. The most substantial year-on-year change is the use of third-party provisioning tools—which has doubled from 12 percent for the application and 8 percent for the database in 2018 to 25 percent and 15 percent respectively this year.

    In increasingly competitive markets, companies rely on software and data to differentiate themselves and drive success. And this, in turn, is underpinned by DevOps and the cloud, which provide the agility, speed, quality and flexibility to develop and deploy software more quickly and safely than before. Businesses therefore need to adopt both if they are to achieve elite performance across their software operations.

    — Matt Hilbert

  • Got DevOps Skills? A Look at the Upskilling: Enterprise DevOps Skills Report

    Got DevOps Skills? A Look at the Upskilling: Enterprise DevOps Skills Report

    IT recruiting is at an all-time high and organizations want T-shaped professionals with cross-functional skill sets to join their teams. While “T” represents an individual’s core competency, and the top of the T represents a broad range of related knowledge, there has been little clarity on which skills are the most important across a wide spectrum of possibilities—until now.

    DevOps Institute launched the Upskilling: Enterprise DevOps Skills survey in 2018 to focus on the human element of skilling. The feedback from more than 1,600 individual responses echoed the notion that regardless of vertical, organizational size, geography or role, DevOps practitioners need data-backed skilling statistics. As the focus within the enterprise, DevOps community shifts from “What is DevOps?” to “How do we do DevOps,” this demand is more crucial than ever. After all, “how to” requires “know-how” and “know how” requires a new set of skills. But which skills?

    According to DevOps Institute’s Upskilling: Enterprise DevOps Skills Report:

    • Soft skills and technical skills are equally important
    • IT operations knowledge received the most “must-have” votes as a functional skill in DevOps
    • Cloud and analytical knowledge are the top technical skills
    • DevOps Engineer emerged as the most popular job title (see below for figure N=812)
    N=812

    The report was developed in partnership with veteran research analyst Eveline Oehrlich, formerly of Forrester Research. This comprehensive data provides indications of which functional, process, technical and automation skills are “must-have,” “nice to have” and “not important.”

    This is particularly significant for IT professionals who are confused about where to focus their personal skills transformations in their journey toward the “T.”

    Should developers work on upskilling their testing, automation, process and/or security skills? Should operations professionals learn to code, test or explore more about machine learning and AI? What about project management and systems administration? The Upskilling: Enterprise DevOps Skills Report can be used as a snapshot of critical enterprise skills that are important to successful digital transformation.

    The Upskilling: Enterprise DevOps Skills Report was released March 4 and is now available for download. On behalf of Platinum Sponsor Electric Cloud, Gold Sponsor CloudBees and Silver Sponsor Lenovo, industry influencers and international DevOps community, we hope this data will help shrink the skills gap and support the transformational goals of both individuals and organizations. We’re already looking forward to the launch of DevOps Institute’s Upskilling: Enterprise DevOps Skills Survey 2020 to continue meeting the demand for ever-evolving skilling trends in the DevOps community—stay tuned!

    — Jayne Groll

  • Report Identifies DevOps Skills in Highest Demand

    Report Identifies DevOps Skills in Highest Demand

    When it comes to DevOps there’s general agreement that a skills shortage is holding back broader adoption. The real issue, of course, is identifying what specific DevOps skills are required most.

    With that goal in mind, the DevOps Institute this week published a report that finds the DevOps skills most in demand fall into three broad categories: automation skills (57 percent), process skills (55 percent) and soft skills (53 percent).

    DevOps Institute CEO Jayne Groll said that, given the fact that DevOps is all about automating repeatable processes, the fact that automation skills are the most sought-after is not all that surprising. But when it comes to process skills, the top five areas where organizations need the most help are software development life cycle (47 percent), understanding of process flow and analysis (46 percent), agile development expertise (42 percent), experience with test-driven deployment concepts and methods (40 percent) and system thinking (39 percent).

    The survey also identifies areas where survey respondents need additional functional skills; most notably, IT operations knowledge (52 percent), security (47 percent), IT infrastructure (44 percent), application design and development (42 percent), quality assurance (34 percent) and testing (31 percent).

    While the survey makes it clear what skills are needed most, it’s less clear whether organizations want to train people with the right attitude toward DevOps skills or find individuals with proven skills. About 30 percent of the survey respondents said they look for soft skills first, with an eye toward training or educating new hires on the process and technical skills later. But 32 percent of respondents said they first look for technical skills.

    In that context, however, it’s also worth noting that 43 percent of the C-level executives and IT management executives that participated in the survey identified business skills—defined as communication, influencing, negotiation, strategic thinking and leadership skills—as being the most important attribute of a new hire.

    Other noteworthy attributes of the organizations participating in the DevOps Institute include:

    • Two-thirds (66 percent) have already adopted DevOps to some degree.
    • More than three-quarters (76 percent) employ agile development processes.
    • Nearly half (47 percent) have adopted the ITIL framework as a best practice for IT service management.
    • Only 10 percent rely on site reliability engineering (SRE) practices defined by Google.

    Groll said the survey makes it clear there is still much work to be done in terms of advancing best DevOps practices. One the biggest challenges are all the silos within IT organizations that have their own nomenclature and culture. Each of those silos creates technical and cultural inertia that must be overcome to integrate processes end to end, she said.

    On the plus side, Groll noted the next-generation of IT professionals are being taught best DevOps practices in academic settings, which means the pool of job candidates with familiarity with DevOps practices should increase steadily. The downside is that it might take a while before those individuals learn enough about the business of the company that hires them to effectively employ those DevOps practices.

    — Mike Vizard

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

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

    I have known of Jeff Williams in the security industry for more than several years. He is a well-respected thought leader in AppSec and OWASP. I finally got a chance to catch up with Jeff and talk with him about Contrast Security, the company he co-founded and how it is helping.

    In this DevOps Chat, Jeff and I discuss the state of application security and how AppSec fits into the larger DevOps realm. Jeff’s a great interview with lots to share.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, DevOps.com, and we’re here for another DevOps Chat. Today’s chat has a decidedly security bent. I’m happy to be joined by Jeff Williams, CTO and co-founder of Contrast Security. Jeff, welcome to DevOps Chat.

    Jeff Williams: Thanks, Alan. Good to be here.

    Shimel: Hey, my pleasure. So, Jeff, you know, as we were talking off mic, this is the first time we’re kinda interviewing anyone at Contrast. Why don’t we—I think it’s only fair we start off with sort of, let’s give our audience a little background. Who and what is Contrast Security?

    Williams: Sure. So, I mean, you know that many enterprises struggle with application security. You know, there’s been an application security industry for like 20 years. I helped to start OWASP back in the early 2000s and I wrote the OWASP Top Ten, and organizations are still struggling with the same problems.

    So, Contrast targets exactly those problems. We are kind of a radically different approach to doing application security. We’re very compatible with DevOps kinds of processes. And basically, we find vulnerabilities so you can shift left in the development and fix them. We analyze open source code, so you can make sure you’ve got safe versions of the components you’re using, and we protect applications in production. And we do it all through dynamic binary instrumentation. So, very much like a New Relic or an AppDynamics, but for security, not performance.

    Shimel: Security prudent security monitoring—excellent. And Jeff, you mentioned, though I don’t know if we’ve spoken like this before, but I’m certainly aware of you for a long time within the security community. This isn’t your first rodeo. [Laughter] You were instrumental in OWASP. You know, we’ve seen application security not—it’s evolved, yes, but it’s still, at the end of the day, it’s about the application, right?

    But yet, you know—look, it used to be, application security meant some kind of app firewall, which—

    Williams: Yeah.

    Shimel: – I’m not saying a WAF isn’t a great tool, it is. It’s changed the game in a lot of ways, I think, in what—

    Williams: Not really. [Laughter] I don’t think so.

    Shimel: Well, it’s made a lot of people a lot of money and it’s taken a lot of venture capital, let’s put it that way, right?

    Williams: Well, that’s not my measure of success. [Laughter]

    Shimel: Yeah. But has it made us safer?

    Williams: Not really, no. No.

    Shimel: But one can argue we’ve done a lot of things and not a lot of them have made us safer, right?

    Williams: That’s right.

    Shimel: You and I have both been in security for 15, 20–plus years, Jeff. And the latest buzzword is DevSecOps, and being that I’ve transitioned to DevOps five, six years ago, and I run DevOps.com and I’m involved in Security Boulevard, I’m all about DevSecOps, and I’m not here to say it’s snake oil or bull or anything like that. But as we were talking about, it means a lot of different things to a lot of different people.

    Williams: That’s right, that’s right.

    Shimel: Why [Cross talk], what do you think it means?

    Williams: Well, you know, to me, DevSecOps is a way of viewing security the way that folks viewed software development through a DevOps lens.

    Let me back up. So, software had a ton of problems 15, 10, 20—I was a developer for a long time back in the early ‘90s and so on. And, you know, software development back then had tons of problems. It was late, it was very error prone, long feedback cycles, slow release times. I worked on one government program for three years, and it never was fielded. [Laughter]

    Shimel: Mm-hmm.

    Williams: So, that kinda thing plagued software. But, I think, DevOps has really revolutionized that, you know, basically just focusing on getting work flowing, creating short feedback loops and creating a culture of innovation of learning. Like, those things transformed the way that software is produced. I love the factory analogies and all that.

    Now, if you look at security, we have exactly the same problems. Security doesn’t really deliver a tangible result. Like, you never know when you’re done. So, the work isn’t defined. That means the work isn’t flowing. You know, we have these tremendously long feedback loops. I did a bunch of work for a major financial institution. They were on a system where some apps got a one year pen test, some apps got a two year pen test, and some apps got a triannual pen test. So, every three years, they would take a look at security. It’s crazy.

    And, you know, so we need to make tighter feedback loops, and security has this culture problem. It’s not a culture of innovation and learning, it’s a culture of enforcing rules and compliance and gates and guards and bottlenecks. And that all can change. If we apply the lessons of DevOps to the problem of creating security in an enterprise, we can define the work, we can create shorter feedback loops, and we can create a culture of innovation and learning. That’s really the challenge. In my opinion, that’s why security continues to struggle is, it’s just not delivering what we want it to deliver.

    Shimel: Yeah. You know, and—look, truth be told, Jeff, that’s what attracted me to DevOps. I thought it was an opportunity for us to kinda reshape the playing board and maybe change the rules and finally deliver—nothing’s perfect, and I don’t think anything is, I’ve seen enough so-called silver bullets to know none of them—

    Williams: Sure.

    Shimel: – [Cross talk] full of crap. But I thought, at least, it shifted the game pieces in such a way that we could, it was a more even playing field, or a better situational playing field for us.

    Williams: Yeah. Done right, I think DevOps can have a tremendously transformative effect on organizations building software. I’ve seen it in a bunch of large enterprises and small companies, you know, and we’re a DevOps shop here at Contrast as well. You know, we’re deploying six, seven times a day, and I have a huge amount of confidence that that makes us deliver much better software.

    And so, my challenge—

    Shimel: Much better software, or much—but is it also more secure? Because shouldn’t that be—I mean, that’s something I strive for, right?

    Williams: Right.

    Shimel: That security becomes synonymous with quality.

    Williams: Yeah. That’s right, that’s exactly right.

    Shimel: Is it more secure?

    Williams: Absolutely, it’s more secure. But you do need some better tools. So, I think, you know, to do security in a DevOps way, you need accurate, real time feedback on the code that you’re building. If you don’t have that, then you have to have experts involved. So, there’s a fundamental relationship. If your tools are producing inaccurate results, then you have to have experts to dig in and resolve the false positives and find the false negatives and, you know, it’s a ton of human expert work.

    That’s not compatible with DevOps. So, you need these accurate tools in order to give real time feedback right to developers. But that’s where instrumentation comes in. If you can get inside the code that you want to test for security or protect against attacks, that’s where all the context is. That’s where the information is. And so, using all that information, you can make really accurate decisions about whether something’s a real, exploitable vulnerability, or whether something’s a real, viable attack. And then you can give that instant feedback, you can create tight feedback loops, and you can deliver security.

    And I’ve seen it work. Companies have transformed themselves from the way they used to be with a big backlog of security vulnerabilities, they’re running scans every six weeks or six months or whatever. They’re piling up vulnerabilities, they’re not really fixing anything, and that’s a very unhealthy way to be. They transformed from there into an organization where they’ve worked off the backlog and now they’re in what I call the new normal. They’re just dealing with new vulnerabilities as they come in, as part of the normal workflow. And it’s massively more cost effective, because they save all that downstream work of tracking and classifying and risk creating and all this stuff. You know, it’s super expensive and doesn’t produce anybody any value.

    Shimel: Yeah. I mean, just, even from the security guy’s point of view to work in that scenario where I don’t have that technical debt, if you wanna call it that—

    Williams: It is—security debt.

    Shimel: Security debt. That’s a great word for it, right? Without that hanging over my head, how much easier and better is my life? And it’s so true. And the other thing, Jeff, is—honestly, until you’re at that point, I don’t think you can talk about automation and velocity and speeding up this whole thing, because when you’ve got all that dreck hanging in your background, you know, you can’t do it, right? You can’t—

    Williams: Well, that’s right. Traditional security is very destructive to modern software development. If you have to involve those bottlenecks and get experts involved, I’ve seen it just wreck DevOps—you know, organizations are trying to do DevOps, but they’re hamstrung by their legacy security teams and processes and technologies. And I wish it wasn’t that way, because security has potential to be a great force for innovation.

    Shimel: Yeah.

    Williams: If you can give people a fantastically secure platform, they can roll out awesome applications and awesome functionality at super high speed. Do things that normally you wouldn’t think you could do, but if you have the platform, you can really make crazy things secure.

    Shimel: Absolutely.

    Williams: It’s just—

    Shimel: I mean, and, you know, I was talking to my friends, John Willis and Damon Edward, they’ve both presented at Dozen, and the notion is, you can have it all. You can have faster applications, better, more secure applications, higher quality—all three, right? You could have two out of three ________, you could have all three doing DevOps and DevSecOps if you’re doing it right.

    But here’s another thing I want to touch on, Jeff, and that is, I don’t know whether it’s shiny trinket syndrome or single-mindedness or we can’t multitask, but just because someone says DevSecOps can do, can make your life better, can do all of the things that you and I are talking about doesn’t mean that we throw everything we learned about security out the door, right?

    Williams: No, no—of course not.

    Shimel: Well, for too many people, they’re like, “Hey, we don’t—okay, man. You know what? Screw that AppSec stuff, we’re just shifting left,” even though shifting left is, you know, fundamentally AppSec. “We’re just shifting left and we don’t have to worry about all of these other CIA things that we learned about, right, traditionally in security.”

    I don’t think anyone’s saying one necessarily replaces the other, or that it—

    Williams: No, I think really it’s more about being extremely clear about the outcomes that you want to achieve with security, and then putting in place a highly tuned machine that can produce those results continuously and repeatedly over the course of a project. Shifting left is a weird term, to me.

    I love the idea of doing security earlier in the process, but many people see that and say, “Oh, well, developers just do security now,” and they wash their hands of kinda the old ways of doing things. And unfortunately, that’s a recipe for disaster. I think you need to empower those developers with technologies that can let them do their coding and not introduce security vulnerabilities.

    And it’s not just about shifting left, because in QA and in staging and CI/CD environments, you want to verify that everything is secure before you push to production. So, you’re really not losing that step. You need to do both, shift left and where it is now. And frankly, I think a lot of organizations should also consider shifting right and doing more protection in production. Because so many organizations that I talk to—I was just talking to a massive technology company here on the West Coast this morning—they’re really pretty blind about what’s going on at the application layer from a security perspective.

    So, to me, it’s not really about shifting left, it’s actually about extending left and extending right and using a DevOps process to produce the outcomes that you really want.

    Shimel: Yeah. I don’t disagree there. The reason I brought it up, though, is, you know, we could point fingers all around, but sometimes the security industry is its own worst enemy, and the cynics and the cynical within—well, we’re consuming ourselves with other stuff right now, but the cynics and the cynical folks would then say, “Oh, it’s just another buzz word, and it’s just something meant to take your eye off the ball, and we have got to hold this thing in our cold, dead hands and not let go.”

    Williams: Yeah, yeah. It’s a fair point. I mean, DevSecOps is a little buzzwordy, and frankly, I’m sympathetic to the folks that say, “No, it’s just DevOps, and security is a part of it, of course.”

    Shimel: Now, that’s my—so, that’s where I am.

    Williams: Here’s how I think about it, though. Let me try and change your thinking about it—it is just DevOps, but there’s a view of the DevOps process that emphasizes the security pieces. It’s very much like a blueprint for your house. You know, you’ve got the elevations, then you turn the page and it’s got the plumbing plant, and then you turn another page and it’s got the electrical plant and so on.

    It’s a little bit like that, for me. DevSecOps is the security view of DevOps. It just emphasizes the security aspects of the DevOps process so that you can see what’s going on and actually understand it in a little different way than if you were just viewing the whole thing all mashed together. It doesn’t really help to just smash it all together and call it all quality. So, that’s how I think about it, it’s just a view of the normal DevOps process.

    Shimel: I don’t necessarily disagree. I think there’s only one DevOps, but I think—I know, I mean, so this year, at RSA, for instance, for the fifth year on the Monday of RSA week at the Moscone Center, we’re gonna be putting on DevOps Connect: DevSecOps Days. And over the course of the five years, we’ve called it DevSecOps, we’ve called it Rugged DevOps.

    Williams: Yeah.

    Shimel: Just don’t call us late for dinner.

    Williams: [Laughter]

    Shimel: And it’s kind of the security community that has driven the DevSecOps name, because they wanna make security is kinda in the middle, I guess. But—hey, whatever. If that’s what it takes to get people on board and doing things to make this more secure, so much the better.

    Jeff, we started talking and I wanted to talk more about Contrast, though. Share with our audience—so, you guys are involved in AppSec, you’ve got a bunch of things going on. Any new news, anything, you know, we are coming into RSA season, everyone always has some sort of news around that. Anything you can share or talk about?

    Williams: Well, I think the big thing for us this year is launching what we call run time exploit prevention, which is sort of our next generation attack detection. And the reason that it’s, I think, so compelling is because it leverages our deep experience in instrumenting applications at run time.

    And so, instead of just trying to block attacks by looking at HTTP traffic and saying, “Oh, well, that’s got a SQL injection in it” or, “That’s got an XXE in it or something.” Instead, we’re instrumented deep within the code, and using that position, we can access a lot more contextual information. We can make really smart decisions about what an attack really is.

    And this is interesting—we’re essentially defusing all forms of SQL injection and deserialization problems and XXE and expression language injection and so on by sandboxing powerful components inside the platforms.

    So, I can give you an example. All these struts and spring vulnerabilities from over the last year and a half or so? They all involve sending untrusted data to an expression language and evaluation engine. So, what Contrast does is, we sandbox those evaluation engines to prevent dangerous stuff from happening while they’re being executed. So, you know, when you’re evaluating an expression, you don’t expect to be starting native processes and accessing files and opening socket connections and stuff like that. So, we prevent all those things from happening during expression language evaluation and restrict the program to only evaluating a normal expression.

    It’s a very powerful technique for ruling out not just known vulnerabilities like in struts and spring, but we’re ruling out all forms of expression language injection, even ones that nobody’s discovered yet. So, I think that’s very exciting and puts you in a really unique position for dealing with new CVEs that are coming out every week.

    Shimel: Yep. Absolutely, and that’s huge. I mean, in spite of everything and in spite of the cynicism, the pessimism, and everything else, it actually is an exciting time to be in development and security, right? We are—

    Williams: I love it. [Laughter]

    Shimel: Yeah. You know, we’re making progress where good things are happening in spite of, you know, every day we still hear about another breach or another, you know, incident.

    Williams: Well, I’ll say this—I think it’s time that every application has the ability to detect if someone’s attacking it, and respond appropriately.

    So, forever, we’ve—basically, our policy around AppSec has been, “Well, let’s build a wall around it to try to keep out the bad stuff, and then let’s scan it to see if we can find where any holes are.” And both of those approaches, I think, have sort of gotten less and less useful over the last seven or eight years, to the point where, today, they’re not really very helpful, particularly on modern applications that are built using APIs, they’re deploying containers in cloud and they move around and all sorts of things. Those approaches just don’t work any more.

    So, fundamentally, building that protection into the applications itself is very compelling to me. It works at scale, it’s accurate, it’s very fast, it’s much faster than building barriers around stuff. And so, there’s just a number of advantages, and I’ve seen it transform organizations from the kind of organization we were talking about before with the huge security backlog, security debt. And they’ve, over the course of a year or a year and a half, they’ve transformed themselves across thousands of applications, to the point where they’re just dealing with the new stuff coming in. They’re in that new normal.

    Shimel: Yep, absolutely. Alright, man. Hey, Jeff, we are—we’re well over our 15 minutes.

    Williams: [Laughter] Awesome.

    Shimel: Yeah, so, we’re gonna have to call it a break on this one. But you know what? Between now and RSA, maybe we can get you back on here, we can talk a little bit more about this. It’s a hot topic, it’s—

    Williams: One quick point, if you want to try Contrast or expose yourself to IAST and RASP, you can use Contrast community edition for free. It’s fully powered, free for one app, and you can just sign up and start using it today.

    Shimel: Where do you get it?

    Williams: It’s at ContrastSecurity.com/ce.

    Shimel: CE. Alright, excellent. Hey, Jeff Williams, CTO of Contrast Security, thanks for being our guest on this episode of DevOps Chat. Until next time, everyone, this is Alan Shimel, have a great day, for DevOps.com, DevOps Chat, and Security Boulevard—take care, everyone.

    — Alan Shimel

  • DevOps Chat: Repos and Nexus Firewall Access, with Sonatype

    DevOps Chat: Repos and Nexus Firewall Access, with Sonatype

    There are really only two repositories of any scale for software components today: the Nexus repo managed by Sonatype and the Artifactory artifact repo managed by JFrog. Up until now they were separate and apart, and working with one was independent of another.

    In a big move toward keeping DevOps open and secure, the Sonatype people have released a plugin that will allow their Nexus Firewall to work with Artifactory as well as Nexus.

    This means that users of both repos can now use the Nexus firewall to make sure that components or artifacts they download are in compliance with the policies they have set up. They can make sure there are no known vulnerabilities to the version users are downloading to use. This is really a big deal and kudos to Sonatype.

    In this DevOps Chat we speak with Wayne Jackson, CEO of Sonatype, and Brian Fox, CTO and co-founder of Sonatype, about what this means for the DevOps community.

    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel, DevOps.com, and you’re listening to another DevOps Chat. Today’s DevOps Chat is breaking some big news from our friends at Sonatype. I’m really honored and happy to be joined by Sonatype Wayne Jackson and Sonatype CF – CTO, Brian Fox. I hope I didn’t mess that up, guys. Wayne, Brian, welcome.

    Brian Fox: Thanks.

    Jackson: Thank you, Alan. Great to be with you and great to be speaking again.

    Shimel: Yeah. Well, Wayne, you and I go back just a couple years.

    Jackson: [Laughs]

    Shimel: Let’s not go and do a history thing. Let’s get right to the breaking news today, and that is kind of a major addition to the Sonatype – I know it’s a firewall. Do you still call it Nexus Firewall or is there a different name for it now?

    Jackson: Yes, we – yeah, that’s correct.

    Shimel: It is the Nexus Firewall. So before we talk about what the major addition is, let’s lay a little groundwork here. What is the Nexus Firewall? Brian, you’re the CTO, let’s give that one to you.

    Fox: Alright, sure. Nexus Firewall is a set of capabilities that allow us to do analysis of components as you pull them into your supply chain through your repository and be able to match that against your policies to enforce things like architecture, quality, license, et cetera, and so specifically it’s intended to be able to stop components from coming into your supply chain when they’re known to be against your policy right up front. So you can stop developers from pulling in a component that has a known vulnerability or pulling in a component that has a incompatible license, those types of things. So that’s the role Firewall plays in the overall portfolio.

    Shimel: Perfect. And, you know, let’s be clear; that – you know, a Nexus Firewall, if it’s in place the Equifax breach never happens for all intents and purposes.

    Fox: Well, that might – what it doesn’t do – you know, it’s not gonna go back and take out the things you’re already input.

    Shimel: You’ve already put in, you’re right.

    Fox: Right. Certainly. If – you know, we still see lots of cases – I think we’ve done some of the studies recently that show organizations are still downloading the same thing that got Equifax attacked, right?

    Shimel: Absolutely.

    Fox: It’s the same version of Strut. So, Firewall would definitely stop that behavior, no doubt, and be able to prevent it from further propagating through your supply chain.

    Shimel: And just a little shout out, Equifax is now a Nexus – a Sonatype Nexus customer, correct?

    Fox: Yeah, that’s correct.

    Jackson: Yes, that’s correct.

    Shimel: So hope – well, at least it’ll prevent the next one, hopefully. So – but guys, so we understand what Nexus Firewall is now, and again, to put in context the importance of today’s announcement, Nexus Firewall worked when you were pulling components out of the Nexus repository up until now. Am I right or am I off base here, guys?

    Jackson: No, that’s correct.

    Shimel: And so the big news today is you’re expanding beyond the Nexus repository to offer protection from artifacts and code and so forth from other repositories.

    Jackson: That’s right. It’s – you know, it’s an acknowledgement, and it may be the first one in this category, that just acknowledges that the DevOps world is heterogenous. You know, there are bunches of vendors and, you know, people within organizations make different decisions and we just acknowledge the need to provide universal protection.

    Shimel: Absolutely. So Wayne, work with me here. It’s the Nexus repository, and with this new release out today you guys are also announcing support and protection for the Artifactory repository, correct?

    Jackson: That’s correct.

    Shimel: And –

    Jackson: And between those two, you know, I’m not sure what the coverage is but it’s gotta be in the 90th percentile of implemented repositories.

    Shimel: I would agree with you. I think between Artifactory and Nexus it’s gotta be I would say high 90’s even, right? We’re not talking 91 or 92 percent. I think it’s probably way up there, and it’s certainly in the billions when you look at the amount of whether it be code or components or artifacts that are contained between the two of them. And Wayne, you hit on it before about the heterogenous nature of today’s DevOps world. It really is; it’s become Artifactory and Nexus as the two big ones.

    But there’s another aspect to the heterogenous nature of today’s DevOps world and that is this whole notion of the software development life cycle, managing the software pipeline, the modern software factory; different companies are calling it different things but it all refers to kind of the way that software is being both written and assembled in – by, you know, modern IT departments today. Why don’t you guys expand on that a little bit.

    Jackson: Yeah, I – it’s been fascinating to watch. As you know, I came from the network security world before Sonatype and had no grasp of just how much software was being written. As I’m sure you know, you know, one of the assets that we manage in the ecosystem is this thing called Maven Central, and last year we served 142 billion download requests, and so – and that’s just in the Java ecosystem and, you know, other ecosystems like NPM are just as big.

    Shimel: Yeah.

    Jackson: And so as we started looking at the patterns in these download requests we started to see this weird disconnect. You know, the disclosure of a vulnerability had almost no impact on usage patterns, and that led us to thinking about, you know, why that might be and how we might think about solving these problems more systematically, and it dawned on us that we had a massive supply chain problem. You know, where the producers of things didn’t have a very effective mechanism for communicating to the consumers of those things because there were just millions and millions of projects that had to be monitored. And so, you know, we started looking at the works of Edwards Deming, who was the guy that transformed Toyota from being a textile manufacturer to the world’s most efficient automobile producer, and it really wasn’t all that complicated. You know, you have fewer, better suppliers, you use the highest quality parts, maintain transparency throughout the system, and don’t pass defects downstream.

    If you can do those four things, lo and behold, [laughs] producing cars becomes a lot easier. And, you know, we concluded that those exact same principles applied perfectly to software where, you know, to your point, you know, now all of a sudden these software development functions, especially in the more modern organizations, look like a software factory, and so let’s use fewer, better projects, let’s use the versions of those projects that don’t have security defects, that have the kind of license that matches our  distribution model and, you know, let’s build a model where we know [laughs] what’s in the system. And if along the software factory assembly line we discover that there’s an issue, stop it there. You know, don’t pass it downstream.

    So anyway, so it’s a model – you know, I’m a little bit of a car guy so it [laughs] certainly works for me, but it feels like a model that’s right.

    Shimel: I agree. It absolutely does. And even before you mentioned Deming, and of course it’s obvious, I was thinking third-party suppliers just like we do see in the automobile industry. But what’s interesting is as you referenced, the sheer magnitude of the numbers here – you know, 142 billion – think about what that means. I mean it’s just an incredible, incredible amount of downloads of usage and everything else and, you know, it doesn’t take many bad apples to spoil the party for everyone, obviously. You know what’s interesting though, guys? Again, getting back to the DevOps community, the DevOps market today, Sonatype is very much – you know, who you are and what – it seems to me anyway – you know who you are, what you are, where you play and how you fit into this.

    And I think that’s in contrast to – you know, we’re in a little bit of a time of upheaval in the DevOps spaces as the market matures and vendors are jostling and trying to – I think some of them might, you know, even be going through an awkward teenage phase, you know, where they’re trying to figure out who they are and what they’re gonna be when they grow up. You know, what – Wayne, you’re the CEO there – what’s the vision for Sonatype? Are you kind of comfortable in your own skin now and what is that role?

    Jackson: Yeah. I think we are comfortable in our skin. I think this embrace of software supply chain management is who we are, it’s who we’re going to be, it’s sort of a unique position to take in the DevOps category, and it allows us to play very nicely with the vendors that are all a part of the assembly line, you know, whether it’s Artifactory or CloudBees or any of the other vendors. And so being able to produce information that gets translated into knowledge that, you know, automates decision-making with regard to supply chain integrity, I think is a good spot for us.

    Shimel: I agree. I mean and not only is a good spot I think it’s a pivotal role to play at this – you know, as we see the continued maturation of the market and, you know, it’s all wrapped around the digital transformation and everything going on. Brian, you know, your background, you were an early chair of the Maven Project. You’ve been in this opensource, you know, world for some time, and Wayne did too coming from the Sourcefire Snort folks, but what’s your take as we see this, you know, maturation? I mean at some level it’s gotta be – I would imagine it’s gotta be encouraging to see cross – like, you know, being able to protect across different repositories, whether it be Maven and Java or Artifacts or what have you, right? It’s gotta feel like we’re making progress. What do you think?

    Fox: Yeah, I think so. I mean our approach since we kind of went down this path, what, 2012 or so is to take an approach that sits above all of the tools, because we recognize from the early days when we were doing a lot of Maven training and consulting and we had the privilege I guess to go to companies and see lots of horrifying processes and all the ways in which attempts to make this better inadvertently made things worse, and we recognize that it requires a sort of across-the-life cycle approach, which means you can’t solve the problem just by adding features to, you know, the repository or the CI. And frankly, given that we were building Nexus Repo Pro back then – I mean we still are, but that was our main product back then – adding it as features on top of the Repo would’ve been the most natural thing for us to do, but we understood through all of that learning that that wasn’t going to be sufficient.

    It required integration to the Repo and to the CI and to the build and to the release automation tools, et cetera, et cetera, right, to be able to most effectively nuance the process of the components that flow through that, because you may choose to respond to a policy violation differently when something is about to actually be pushed into production versus something that’s just happening in your – you know, on every commit CI build. And so for that reason, being able to integrate into all of these tools, including all of the different repos, is just natural. It’s a natural evolution of the approach we’ve been taking the whole time.

    Shimel: Got it. So, I guess the next question is now that we have – you know, between the two repositories we’ve got high 90 percent of the market – how do we get 90 percent coverage with this Firewall product, right? I think we’d all sleep better. You know, what is the key, guys, to getting more people to realize this is kind of a no-brainer that they need to get done here, right? I mean what do you think is preventing us from really seeing this?

    Fox: Culture. Culture and history. I think there’s a history of application security tools specifically that, you know, are prone to false-positives just by the way they worked and led – and a history of bad approaches, like I was talking about before, that tried to force bad tools onto development that ultimately led to rebellion or disuse and gear grinding, and so in some ways the security tribe I think has become a little bit afraid to engage development in a lot of organizations, right? So they very much try to work at the end of the process, try to produce lists. We know that those things tend to get ignored, that they don’t usually have a profound effect on what’s happening, and so the organizations that are really successful are the ones that, you know, can set all of that history aside and still work together in a DevSecOps type of way and, you know, look at the problem holistically and understand that, yeah, actually it makes sense. If we can stop the bad things from coming into the process to start with we don’t have to chase them out later.

    The security guys don’t have to track it in the list and the Dev guys don’t have to go rework it, right? And so, you know, that’s kind of the approach that we’ve been trying to take, that all of these different constituents have an important job to play in the success of a business and it works best when [laughs] they’re all working together, not working against each other and throwing grenades over the walls.

    Shimel: Absolutely.

    Fox: And so really, you know, the biggest hurdle to adoption in most places just simply is that culture and the history of disdain and things like that.

    Shimel: Yeah, I agree, Brian. And guys, I’m gonna tell you something. Here’s a private theory that I’ve been working on and I’m gonna be speaking about it in the months ahead. You know, we’ve worked really hard – Sonatype more than most any other vendor I can think of – to advance the cause of DevSecOps. You know, Derek and Mark on your team and myself have been putting on DevSecOps events at RSA for the last five years now, and we do it in Singapore at RSA and we go all over the world with this DevSecOps thing. And recently, in the last couple months, I’m starting to see sort of a bifurcation in how security is dealing with DevSecOps, right?

    I’m seeing some companies that are embracing the Dev sides of things, and let’s call that DevSec. They’re working with developers to make the code more secure and make sure that pre deployment and everything is tested, everything is secure, and we release really tight, good quality, right? Security is synonymous with quality, and let’s call that DevSec. Then there’s another group of vendors, Brian, that are dead into what you’re talking about, right? They’re almost afraid, intimidated, or just fed up with dealing with developers, and they’re really focusing on the post deployment aspect of things here, right, and let’s call that SecOps, because they want to work more with the Ops folks, post deployment, you know, monitoring and that kind of thing.

    And I’m not saying that there’s not a reason to do that or it’s not right to do that – it absolutely is – but when we start looking at it as DevSec and SecOps, we’re committing the same mistakes that we did to begin with and we’re losing that it is DevSecOps for a reason. It’s Dev and Ops and Sec all working together. We can’t say, “Oh, we’re gonna work with the Ops guys but not the Dev guys or vice versa.” It’s gotta be everyone’s in it to win it. And I –

    Fox: Completely agree.

    Shimel: But I’m – yeah – but I’m seeing security vendors now kind of, you know, taking sides here on this. I’ve recently done a few podcasts – and some of them are new companies that are launching or coming out of stealth and RSA, and they’re growing this distinction that they’re SecOps, not DevSecOps, or they’re DevSec, not Dev – and I think it’s a huge mistake, a huge mistake.

    Fox: I think that’s largely led by the constituent. If you go and talk to the security guys, that’s what they’re gonna tell you that they want, right? It’s part of that history.

    Shimel: Yeah.

    Fox: You know, so if you allow yourselves to be pulled directly in the direction of what people want based on their perceived understanding of just how things work and that’s the way it’s always gonna be, that’s I think where you end up, so you have to buck that trend a little bit and say, “Guys, it doesn’t have to be this way. It can be better.” But we have to work together to do it, right, and we have to think about things a little bit differently. You know, and I have many conversations – you know, it’s happening more and more as AppSec and OPSEC is becoming more generally aware of the opensource component, you know, risk. They’re starting to come at the problem, but unfortunately they’re just trying to add more data to their existing process, and I have to remind those guys all the time that developers are picking new components all the time, they’re picking new versions of those components all the time.

    They’re not only doing it because you handed them a list of vulnerable components or a list of CVEs and said, “Fix it or else,” right? So wouldn’t it be nice if you had a process and a set of tools that could support them in that behavior so they don’t come on your list later? [Laughs] Right? And a lot of times that is like a shocking realization to that tribe, right, and that’s that culture that I was talking about. It’s a big challenge.

    Shimel: Agreed. And look, our work is not done, right? That’s what that means to me. We still have more work to do evangelizing DevSecOps and making sure people under – take a whole holistic aspect to it, and it goes back, Wayne, to what you were talking about in terms of the pipeline and the software, you know, automation and pipeline kind of thing, is it’s not bifurcated at the pre deployment versus post deployment juncture or junction. It – DevSecOps is about the whole thing from end to end.

    Jackson: Yeah, the organizations that can think about this holistically are just bound to be more effective and more efficient and, you know, to your point about evangelism, I mean one of the things that we’re going to see, and I think we are seeing, is that the most highly-performing organizations are the ones that are getting it.

    Shimel: Yeah.

    Jackson: They’re the ones that are gonna be leveraging software to more effectively differentiate their business. [Laughs] And at some point, unless you want to lose, you’re gonna have to start thinking about the ways that these, you know, forward-thinking, advanced organizations are doing what they do to make themselves better every day.

    Shimel: Absolutely. And you’ll have winners and losers, and look, that’s capitalism and that’s the market dynamics at play, right? You can adapt or die or not, right? I mean it’s up to you. Guys, we’ve spent a lot of time talking, you know, about this at a macro level. Brian, if you don’t mind, I’d like to get a little geeky on you and ask if you can explain to our audience at a nuts and bolts level really what’s going on with the Nexus Firewall.

    It’s software, right? It’s not an appliance, per se. Where does it sit, how does it intersect, how do you set policies in it? You know what I’m saying? Let’s give our audience a little bit of a…

    Fox: So our Nexus platform is kind of composed of maybe three parts. At the core is a piece of software that you run on prem or in your cloud that we call the IQ Server, and this is the thing were you define your policies, it’s the database of all of the components and which applications they’re used in, the dashboarding, the reporting; you know, all of that type of stuff occurs within the IQ Server. The IQ Server works with services that we have in our cloud to provide the real-time information around the components and the security and the licensing and all that type of stuff, right? So that’s a real-time feed, it’s not a data dump that you have to download periodically.

    And then there’s all of the plugins, the plugins that go into all of the places I mentioned before; your build, your IDE, your CI, your repository, your automation tools, et cetera, right? And so what we’re talking about here is we’ve added a new plugin that plugs into JFrog Artifactory. So when a component is being proxied from an external repo, such as Maven Central, the plugin will do the analysis of the thing being requested, it will understand what it is, work with the IQ Server to understand if it’s in compliance with the policy or not, and the depending on how the policy is configured it can either allow it, it can quarantine it, or it can just outright block it, right? So that’s the same capability that we’ve had for a couple of years now inside of the Nexus repository, so it replicates that functionality for our JFrog users.

    Shimel: Fantastic. Wayne, how are we going to market with this?

    Jackson: I get that question asked to me a fair bit, and we have a very multifaceted go-to-market model. You know, we still have folks that are very senior out in key regions that are evangelizing, because this is still an immature market, but increasingly as the market’s maturing are starting to lead with product and product capabilities in our marketing function. So, a mixed model, but one that we think aligns with where the market is in terms of its maturity, you know, that will change over time.

    Shimel: Understood. Guys, we’re almost out of time. If it’s okay I wanted to return back to the DevOps market in general. Wayne, you know, you and I kind of saw the security industry mushroom, right, from let’s say early 2000’s through even 2008, ’09, ’10, you know? I – and we now have both – and have both seen the DevOps market mushroom, you know, from 2013, ’14 to today. It’s only been four or five years. And, you know, we touched on it earlier with companies trying to kind of jostle for where they are, what they do and how they fit into this brave new world. You know, put on your visionary hat, if you will. Where’s this going? Where is it – you know, is there a logical sort of conjunction of security in the DevOps? And if so, what does that mean for the broader market? What do you think?

    Jackson: I disagree with you a little bit in that – with regard to DevOps having mushroomed. I think we in the industry kind of feel like it has because now all of the sudden people are starting to use our words back at us, but I think in terms of, you know, DevSecOps being a mainstream thing that’s just a part of how people work is still a bit away, and I think, you know, the work that you’re doing, I think the work that we’re doing and other vendors in this space is still enormously critical because even organizations that aspire to DevSecOps still need help. It’s not an easy thing to embrace and implement, as you know, and so there’s still some work to do, which I think is cool.

    Shimel: Yeah. Well, it keeps me going every day and gets me up. And you’re right, you know, we tend to forget that we live in a bubble. When you’re a hammer, everything looks like a nail, right?

    Jackson: [Laughs] Right.

    Shimel: When you’re talking DevSecOps all the time people tend not to look at you and say, “What are you talking about?” So, you know, we kind of breathe our own exhaust, if you will. But there is, there’s a lot of work to be done, even – forget DevSecOps – even in the basic DevOps level, right? When you – a lot of companies have dabbled in DevOps but how many are truly end-to-end DevOps, right, and that number I’m gonna guess is well – is below 20 percent, probably closer to 10 percent.

    Jackson: I think you’re right, I think you’re right.

    Shimel: Yep. So our work is still in front of us. But hey, you know what? It wouldn’t be fun if it wasn’t, right? I mean that’s what keeps us –

    Jackson: [Laughs]

    Shimel: Anyway, guys, when is this new plugin for Nexus Firewall available?

    Jackson: More or less now.

    Shimel: Okay.

    Jackson: I think the official release date is March 1, but yeah, happy to show it to anyone who’s curious to see and very proud of the technology.

    Shimel: Absolutely. And they can get more information at Sonatype.com?

    Jackson: That’s right.

    Shimel: Fantastic. Wayne Jackson, Brian Fox, CEO and CTO, cofounder of Sonatype, respectively. Thanks for being our guests on this episode of DevOps Chat.

    Wayne Jackson: Thank you. It’s been our pleasure.

    Fox: Thanks for having us.

    Shimel: Always a pleasure. Always a great time, guys. Okay, this is Alan Shimel for DevOps.com. You’ve just listened to another DevOps Chat. Have a great day, everyone.

     

    [End of Audio]

    — Alan Shimel

  • How SRE Creates a Blameless Culture

    How SRE Creates a Blameless Culture

    People in tech love to praise failure as essential to innovation. But at far too many organizations, when failure happens, it is punished. When an IT system goes down, an individual or a team is immediately ID’d, blamed and shamed. This is counterproductive. Blame damages companies by creating a play-it-safe atmosphere and stifling innovation; even worse, when mistakes are made, they are often hidden.

    Fortunately, more and more organizations are recognizing the damage that blame can do and embracing a blameless culture. This is a big shift, yes, but companies can make the move to blameless—and make it stick—if they bring site reliability engineering (SRE) best practices to their technology teams.

    Why Blame is Bad

    I’ve worked at several fast-growth companies that suffered under a culture of blame. At one, we were scaling quite rapidly. Change was constantly being introduced to the infrastructure, which meant that it broke all the time.

    Because we had customers running their core business on our systems, our reliability requirements were very high—so high that for a while we stopped feature development altogether, in fear that new features would bring our systems down.

    This was difficult enough, but the culture of blame made it worse. There was no psychological safety net and fingers were pointed constantly. There was an us-versus-them mentality—engineers versus non-engineers, developers versus operations, developers versus developers. Developers dedicated way too much mindshare to protecting themselves and their domain.

    In a blame-rich environment, developers who should be delivering concrete results spend too much of their time in meetings trying to justify their work. There is a culture of retribution for mistakes. This leaves little room to learn and grow from failure because developers get harassed by management when they do make mistakes, or they get fired.

    Your best people—those empowered to make decisions—see their responsibility undermined and go elsewhere. Creativity and innovation slow to a crawl. Meanwhile, competitors run ahead.

    Why Blameless is Better

    In a blameless culture, everyone feels safe and no one is afraid to make mistakes. It’s a psychologically secure environment, where true DevOps can happen. Developers feel confident enough to express their ideas and take chances. Development folks and operations folks collaborate well, and everyone is aligned on the problem.

    The work environment is positive and workers are assumed to be doing their best. When mistakes happen, people aren’t blamed. Instead, any error is viewed as a manifestation of an underlying vulnerability in the systems. Attention is focused on fixing those vulnerabilities and, as a result, systems are constantly improving.

    How to Get to Blameless

    Let’s say you just had an outage and your database crashed. Don’t start by placing blame on a team or individual. Rather, start by conducting a postmortem. Ask questions and find the answers: Why did the database crash? Because Alex pressed the wrong button. Well, why? Because we didn’t have a system in place to enable automatic checking or a review process. So why did we not have that?

    Now you’re getting to blameless and you’re reaping the benefits. You’re having a productive conversation and you’re focused on fixing your systems, not affixing blame. It’s not about Alex pressing the wrong button; it’s about how your organization is not set up to ensure success. It’s about this vital opportunity to learn from a mistake and get better. Don’t fire Alex. Put a solution in place so the problem doesn’t happen again.

    How SRE Can Help

    To get to a truly blameless environment, you need to implement SRE best practices. Why? Because SRE creates ultra-scalable and highly reliable software systems, by building in automation and tooling—moving the human element out of the picture and focusing on the systems.

    One of the founding principles of the SRE movement is blamelessness. By implementing an SRE team and establishing SRE practices, your organization can move from the traditional operational model of break-fix to an environment that applies a development approach to IT operations, with the goal of improving reliability via automation, continuous integration and delivery.

    For this to happen, you will need a SRE champion to quarterback your SRE effort. You will also need organizational buy-in to blamelessness. It has to be practiced top-down and have the full support of all leaders in the organization.

    Tooling is critical, too. Look for tools and dashboards that can quickly do postmortems and find action items that need attention, that can identify the most commonly impacted services, products and customers, and the contributing factors that most often lead to incidents. The right tools will help you resolve incidents faster, by providing a clear overview of metrics related to incident identification and the actions that need to be taken.

    You want to move fast and be innovative. But can you do it reliably? With a blameless culture, you can. You’ll have a safe environment that attracts and retains the best talent. You’ll move quicker, because you’ll be focused on fixing systems that break and finding out why—not the blame game. By delivering a higher degree of reliability, you’ll build greater trust with your customers.

    You’ve heard the saying: Failure is not an option. In a blameless environment, failure is always an option—because it means that systems are always improving and innovation is always happening.

    — Ashar Rizqi

  • FinOps Foundation to Help Rein in Cloud Costs

    FinOps Foundation to Help Rein in Cloud Costs

    A new consortium has been formed to promote best practices for controlling cloud computing costs.

    Announced at the Cloud Economic Summit, the non-profit FinOps Foundation counts among its founding members Atlassian, Autodesk, Cloudability, HERE Technologies, Just Eat and Nationwide.

    Cloudability co-founder J.R. Storment said the goal is to bring financial accountability to variable cloud spending that can easily spiral out of control if not monitored carefully. The adoption of best DevOps practices makes IT organizations more agile, but not every organization has the financial controls in place to ensure spending on cloud services is aligned with business outcomes, said Storment.

    These days engineers can use their corporate credit card to spin up virtual machines in the cloud. The FinOps Foundation is making a case for more accountability over the spending.

    Gartner estimates worldwide cloud spending will reach $360 billion by 2022, which is five times the compound annual growth rate for overall IT spending. The unfortunate truth, however, is that most finance organizations don’t have a lot of visibility into how those dollars are being allocated.

    To coincide with the launch of FinOps, 451 Research also published a survey of 300 IT and finance executives in the United States and the U.K. that finds more than half (57 percent) of large enterprises worry about cloud costs daily, with 80 percent admitting poor cloud financial management has had a negative impact on their business.

    In fact, the 451 Research report makes it clear most finance departments have little visibility into cloud spending. Almost three-quarters (72 percent) of finance executives acknowledged they have no formal reporting capacity between departments. More than half (51 percent) of respondents admitted to occasionally overspending and 68 percent said they are only alerted to overspend too late. A full 82 percent of finance respondents rely on cloud vendors, spreadsheets and manual processes to track cloud costs.

    Despite much of the variable cost hype surround cloud computing, 73 percent of the finance respondents in the United States and 81 percent in the U.K. still treat cloud as a fixed capital expense rather than an operating expense.

    To help finance teams better understand how cloud spending is being allocated, the FinOps Foundation will provide access cloud economic research and related articles, FinOps training and meetup groups. Early access to the forthcoming “Cloud Financial Management Strategies, Creating a Culture of FinOps” book published by O’Reilly Media will also be provided.

    As IT organizations increasingly employ multiple cloud platforms to run different classes of workloads, understanding the true cost of choosing to use one cloud over another will become more important. At the same time, IT organizations have a greater appreciation for the need to move workloads between platforms as costs rise. Just because an application workload was created in the cloud doesn’t mean that workload should be deployed there. Many long-running applications are less expensive to deploy in an on-premises IT environment. The challenge IT organizations arguably face going forward will be integrating streams of real-time financial data into DevOps processes to make more economically informed decisions about how to allocate their cloud resources.

    — Mike Vizard

  • Top Trends in DevOps for 2019

    Top Trends in DevOps for 2019

    DevOps is poised for healthy growth over the next several years, with analysts large and small weighing in with forecasts. For instance, IDC predicts the worldwide DevOps software market will reach $8 billion by 2022, up from $3.9 billion in 2017. Similarly, Grand View Research estimates the global DevOps market will hit $12.85 billion by 2025, registering a CAGR of 18.6 percent.

    Below are some of the most influential trends driving growth in 2019.

    DevOps Instrumentation in AI and Machine Learning will Increase Productivity Gains

    Web-based forms are the nemesis of process automation. Everyone dreads manual forms, but that’s what organizations use when they want to capture data from customers, employees or partners.

    AI and machine learning technologies are mature enough to reliably process voice, video, text and images. That means data-enriched forms could be filled out simply by making a phone call, taking a video, taking a picture or some other natural activity. The analog inputs from the external world are captured digitally and automatically.

    Of course, the error rates in such conversions would depend on how well the AI models have been trained and how well we use the real-world input to enhance the model. DevOps-level instrumentation needs to be introduced in the pipeline. That way, either the customer or the person in-loop will be able to take these errors as inputs for enhancing the accuracy of the models.

    Key Management is Key for DevOps

    In 2019 and beyond, data usage will be closely monitored as GDPR becomes a reality and similar privacy laws are passed across the globe. This is when data tagging becomes critical. Therefore, tools related to data tagging and master data management will become crucial for tracking the origin of data usage.

    Sensitive data will need to be encrypted in rest and in motion. Along with data encryption comes the important responsibility of managing encryption keys. Not only should the keys be stored securely, they also may need to be rotated. Key management services that offer such functionality will become commonplace in the DevOps world.

    Container Adoption Increases with Data Locality Demands

    Data locality is driven by countries that mandate data must reside within their geographical boundaries. Enterprises using SaaS or PaaS will use country-specific public clouds or even private clouds. As a result, critical data and applications will have to be deployed across geographies. Deployments will become more complex due to geographical expansion as well as agile development methodologies.

    In response, container-based development, release and deployment models will become commonplace within the enterprise. While containers offer many advantages by creating siloed workloads, they also increase the demand for sophisticated monitoring tools and technologies that help consolidate the view of these applications.

    The Compiler is the New King of the Data Center

    The demise of Moore’s Law is not helping the CPU keep up with increasing workloads in the data center. To bridge the performance gap, modern hardware such as GPUs, FPGAs and ASICs will infiltrate the data center.

    Developers will start using higher-level languages such as OpenCL and CUDA, and the compilers will generate code to run on the various hardware, depending on deployment-level input including workload, hardware configuration and data size. DevOps practices will have to start befriending compilers so that code can be generated just in time, very close to the point of deployment.

    Technological advancements, security requirements and legislative changes will impact the professionals within this sector, which is growing at a rapid pace that could see it double within five years. As developers prepare to manage a higher volume of sophisticated data, an increasing amount of DevOps solutions will enter the market to further automate processes, accelerate deployments and address the above trends.

    — Shailesh Kumar Davey

  • New Relic Accelerates AIOps with SignifAI Acquisition

    New Relic Accelerates AIOps with SignifAI Acquisition

    New Relic, following its acquisition of SignifAI, is in the process of accelerating its investments in machine learning algorithms and other forms of artificial intelligence (AI) as part of an effort to make it easier to separate the signal from the noise created by all the alerts in an IT environment.

    Aaron Johnson, senior vice president of product management at New Relic, said SignifAI represents an opportunity for New Relic to create a superset platform that can apply advanced analytics to a much wider range of data sources. SignifAI has already created more than 60 integrations spanning open source and commercial monitoring tools that are widely used across DevOps toolchains, he noted, adding that as New Relic moves to add other data sources, there’s an opportunity for the company to distinguish itself beyond providing software-as-a-service (SaaS) tools for monitoring applications and infrastructure.

    It’s obviously still early days for AI in the realm of DevOps. But it’s also clear that with the rise of microservices and containers, soon it will be impracticable for IT organizations to manually manage their IT environments. Various forms of automation based on AIOps platforms infused with machine and deep learning algorithms will be required. As a provider of SaaS-based tools for monitoring applications and infrastructure, New Relic already has access to vast amounts of data required to train AI models on optimizing a specific IT environment.

    Of course, there’s lots of competition across the IT monitoring category, so it remains to be seen which vendors will have the resources required to drive continuing investments in AIOps.

    In the meantime, DevOps teams will need to adjust their processes to take advantage of AIOps. It’s unlikely AIOps platforms will eliminate the need for DevOps teams, but the number of applications and platforms any DevOps team must manage effectively will increase substantially. Rather than replacing humans, AIOps platforms will reduce the pressure to hire additional IT staff when professionals with DevOps skills are already in short supply. The AIOps platform, for all intents and purposes, acts like a co-pilot.

    The biggest issue IT organizations are likely to encounter along that journey is establishing trust with any AIOps platform they implement. It takes a while for most AI models to learn the IT environment before that platform makes any reliable recommendations. In most cases, DevOps teams will have to dedicate staff to train and update AI models continuously as the IT environment changes. It may take years, however, before DevOps teams are comfortable enough to move beyond trusting a recommendation and enable an AIOps platform to automate processes on its own. After all, the only thing worse about being wrong about any IT decision is being wrong about it at scale.

    AI at this point is all but inevitable in DevOps environments. But it doesn’t necessarily follow that just because something is based on AI it always will be smarter than experienced DevOps professionals.

    — Mike Vizard