Category: Features

  • DOES 2019: Understanding the Effects of Burnout

    DOES 2019: Understanding the Effects of Burnout

    If you work in the IT field, cybersecurity, the startup world or any other high-pressure job, you or someone you know has probably suffered from burnout in one form or another. If so, you already know that burnout is a real condition with significant consequences. In fact, the World Health Organization (WHO) recently recognized burnout as an occupational phenomenon.

    The WHO describes burnout as follows:

    Burn-out (sic) is a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed. It is characterized by three dimensions:

      • feelings of energy depletion or exhaustion;
      • increased mental distance from one’s job, or feelings of negativism or cynicism related to one’s job; and
      • reduced professional efficacy.

    I have been on the road pretty much constantly for the last three or four months (no, I am not trying to say I suffer from burnout). We have covered lots of great conferences. One of the best, as usual, was Gene Kim’s DevOps Enterprise Summit in London. We have about 30 videos from the conference up on the Digital Anarchist site. Of those interviews, my favorite is the one in which I had a chance to sit down with three PhDs to discuss the issue of burnout. I say three PhDs not just to throw around titles—these are three recognized experts in their field.

    The trio of panelists are:

    Dr. Christina Maslach — Probably the foremost authority in the world on burnout.

    Dr. Steven Spear — Senior Lecturer at MIT Sloan School and the Engineering Systems Division at MIT.

    Dr. Nicole Forsgren — Founder of DevOps Research and Assessment, now part of Google.

    This interview is a little bit longer than most, slightly more than 30 minutes. But I think it is well worth your time to hear what these three experts have to say on the issue of burnout and workplace fatigue.

    In addition to our interview on the Digital Anarchist set, I am also happy to include the panel discussion these three folks had on the main stage of DOES London with Gene Kim.

    More importantly, if you or someone you know is suffering from burnout symptoms, please reach out for help and do something about it. You are not alone.

    Don’t forget! DevOps Enterprise Summit Las Vegas 2019 is happening Oct. 28-30 at The Cosmopolitan Hotel. Be sure to register here if you haven’t already and join us for the premier event for technology leaders of large, complex organizations implementing DevOps principles and practices. You can also preview the event by watching presentations from past DevOps Enterprise Summits.

    — Alan Shimel

  • DevOps Chat: Armory Discusses $28M Funding, Continuous Delivery

    DevOps Chat: Armory Discusses $28M Funding, Continuous Delivery

    The tribe at Armory announced the company‘s $28m series B funding, led by Insight Partners. Armory enables continuous software delivery at enterprise scale, powered by Spinnaker.

    That is a crisp mission statement, but beyond that Armory is bringing the open source Spinnaker to the enterprise market. As such, they are also helping the entire Spinnaker community and as part of this the entire CD market. They are members of the CD Foundation and part of the Linux Foundation as well.

    In this DevOps Chat, I had a chance to catch up with Armory’s founder/CEO, DROdio and VP of marketing, Carl Landers to talk about Spinnaker, CD and the state of software delivery.

    BTW, if you are interested in learning more about Spinnaker and will be in San Diego for CloudNative.com/KubeCon, the Spinnaker Summit is the weekend before. The Armory folks have been nice enough to arrange a 20% discount if you would like to go:
    www.eventbrite.com/e/spinnaker-sum…=ARMORYAUGUST20. The code for discount is ARMORYAUGUST20.

    Also, you can join the Spinnaker Slack channel at: join.Spinnaker.io

    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 you’re listening to another DevOps Chat. We’ve got some exciting funding news on today’s DevOps Chat. A company I’ve been familiar with now for a few months, Armory, Armory.io—is it Online Networks, DROdio, or just Armory?

    DROdio: Just Armory.

    Shimel: Armory. And—well, they let that cat out of the bag. I’ve got with me the Armory CEO and Founder, DROdio. DROdio, welcome.

    DROdio: Great to be here. Thank you, Alan.

    Shimel: And some people, if you’re wondering out there, when I first met DROdio, he told me it’s like rodeo with a D, so if you’re wondering how to say it, that’s how you say it. But DROdio, just for the record, give our listeners your real name, your full name.

    DROdio: Yeah, so, my full name is Daniel Rubén Odio, and I go by DROdio. It’s my handle on everything, so DROdio is easy.

    Shimel: Okay. And then joining DROdio and myself today is—well, DROdio, why don’t you introduce Carl?

    DROdio: Sure. I’m very happy to welcome Carl to Armory. Carl has recently joined us, our VP of Marketing. Carl, I’ll let you introduce yourself.

    Carl Landers: Welcome to everyone who’s listening. This is Carl Landers, and I’m happy to join you, and I’ve been with DROdio at Armory for a couple of months, and we are excited to share news today about what’s happening with Spinnaker and with Armory. Alan, it’s great to be here.

    Shimel: Thanks, Carl. Hey, and it’s a pleasure to have you here. So, we’re gonna jump into Spinnaker and Armory and go a little bit more in depth in that in a moment, but let’s take care of the news first. The big news is, you’ve announced a series B of $28,000,000.00, and it’s led by Insight Partners, correct?

    DROdio: That is correct. Very happy to have Insight joining our board. Insight has seized the same opportunity that we do, which is that there is a large category forming in software delivery that could never be a category before, and we can talk a little bit about why that’s changing, but Lonne Jaffe is gonna be joining our board as the newest board members, and I just—I couldn’t be more thrilled about having Insight involved and funding Armory’s growth.

    Shimel: Well, and again, let me just fill in with a little background. For those who may not be familiar with Insight Partners, I think the number is something outrageous, $25,000,000,000.00 under management or something like that. And they are the folks who have really financed a ton of, or a bunch of really blue chip companies in the DevOps space, including companies like JFrog and Tricentis and now Armory, and more than several others, really doing a nice job there.

    Lonne Jaffe from Insight is joining the board, you mentioned, DROdio. Any just—I mean, do you know his background that you can share? What does he bring?

    DROdio: Yeah, so, Lonne is an especially good board member for us, because Lonne has a deep background in AI and ML and really understands that space well. And Alan, I’m sure that you know this and probably the people listening also understand it—software delivery is, especially into the cloud, is just in the first innings of a very long game. So, really, a lot of what’s happening today is focused more around automation.

    And, in that process, as software delivery matures, we see a lot of opportunities to really make it smarter and unlock a lot of data across the SDLC. So, having Lonne on the board just positions Armory extremely well to be a leader in that over the coming decade. So, very happy to have him involved with that deep level of expertise.

    Shimel: Absolutely. We’re gonna dive more into that as well in one second. Just, last question or last point I wanted to make regarding the announcement—you know, Insight led this round, I take it, but you also have some pretty nice names on your investor list even prior to this, right, if I’m not mistaken?

    DROdio: Yeah, we’ve been very blessed. You know, we started in Y Combinator’s W17 batch and we’ve had Noah Doyle from Javelin was our seed investor, Crosslink with a series A investor, Celeal from Bain has participated in a number of rounds. So, we also recently had Robin Vasan from Mango join as an investor as well.

    So, we just—you know, we were lucky to have a lot of great angel investors, including Eric Reese, the kind of father of the lean startup series; Andrew Miklas, a founding CTO of PagerDuty; and other angels like that. So, you know, we just—we’re in a bit of a special situation with Armory. We just, we’ve never had a hard time fundraising. I think a lot of that has to do with just this massive shift of computing into the cloud and all the challenges that come along with it.

    Shimel: Yep. Alright. We covered the announcement well. I think we did it justice. Let’s dive in now, guys. So, look—when you talk about Armory, you can’t talk about Armory without talking about Spinnaker, right? And again, in our audience—well, our audience is pretty savvy to this stuff. They probably have heard of Spinnaker. Spinnaker, of course, came out of the Netflix kind of factory there that brought so much great software tools to the forefront. But it was also—you know, Spinnaker was the father of, I mean, if Netflix was the father of Spinnaker, Google is the godfather. And, you know, they’ve done a lot for us.

    But I’m not giving it justice. DROdio, you’re much more well versed on Spinnaker. Carl, I don’t know how much of the Spinnaker story you know, but guys, give us the background.

    DROdio: Yeah, sure. Why don’t I—before we talk about Spinnaker, actually, let’s just talk about some of the trends that we’re seeing in computing and then back into how Spinnaker is solving for some of that.

    So, you know, we’ve been working with large enterprises, Fortune 500 and Global 2000 enterprises. And what we’re seeing—and I don’t think this will be a surprise to anybody who is deep in DevOps—is, enterprises are recognizing that, in order for them to thrive over the next decade, they really have to become software companies. Now, they may not die. They may just survive. But in order to really thrive, they have to make big investments, and their ability to take an idea and get it out into the world with safety and velocity—so, to really become good at navigating the SDLC, the software development life cycle.

    The big shift that we’re seeing is that companies are starting to move out of data centers and into the cloud, and what we’re seeing is—and I actually don’t think that every engineering leader is quite seeing it this way yet, but what we’re seeing is that a company’s path to production in a data center was a very static one. It didn’t change. Maybe they were running The Sphere. But they could afford to build it themselves, and they had to build it themselves because every data center’s different.

    And so, they would use these, what we would consider legacy kind of mutable configuration management tools like Chef and Puppet and Ansible to build these brittle paths into production, into their data centers.

    Well, that’s changing. The infrastructure layer is going from being very static to very fragmented, and we think that’s just beginning. There’s so much innovation coming from Amazon and Microsoft and Google that large enterprises, which have been building their own roads into production, are having a hard time dealing with this dumpster fire of innovation that’s coming from the cloud. I mean, if you look at AWS, it’s more than just AWS, it’s EC2, it’s ECS, it’s EKS, it’s Fargate, it’s Lambda—it’s whatever AWS is gonna announce at re:Invent in November. And, you know, that’s just AWS, let alone GCP or Azure or Pivotal or Oracle.

    And so, you know, when I talk to CIOs at Fortune 500 companies, they have a big problem, which is that they have these legacy and brittle paths to production that are not set up to enable them to really take advantage of this just massive amount of innovation that’s happening in the cloud. And so, they have a hard time actually getting their ideas out as features into the cloud.

    Netflix, as it started moving out of data centers and into the cloud a decade ago, recognized that there was a need for a platform that would not only codify the process of going from idea to featured production—so, that’s really all of the kind of human and cultural aspects of writing code and getting it out into the world. So, things like different stages. So, manager approvals, different environments, Dev/Stage/Prod, code scanning, vulnerability scanning—all of those things, security policies, compliance policies codify all of that into one golden path, but then also allow a company to have workload portability. So, allow a company to be able to decide if that code should go in as a VM on AWS or into a data center running Kubernetes.

    And so, they built Spinnaker to become much more sophisticated about really leveraging all of those different cloud targets. And so, now, they’re giving it away, right? Netflix and Google have codified the kind of decade of best practices they have at delivering software into the cloud, and they’re giving it away to anybody that is serious about becoming a software company.

    And so, that’s the real big opportunity that we see is to bring this open source project that codifies these best practices into Global 2000 and Fortune 500 companies that are serious about being able to thrive and not just survive over the next decade.

    Shimel: Absolutely. And a couple things there, right? As widespread as open source adoption is—and it is, it’s 95 percent penetration or higher—Global 2000 and Fortune 500 companies, when they do adopt open source, especially something platformish like Spinnaker, want to have some commercial entity usually wrapped around there, someone who’s gonna help provide support, and someone to go to if there’s a problem, someone who’s gonna continue kinda pushing the ball forward in terms of development. And that’s a role, right, that Armory is sort of fulfilling in the marketplace—the commercial Spinnaker.

    DROdio: Absolutely. Very much so. So, there’s a couple things about that. Spinnaker—I mean, if you think about what a company needs to do to become software first, the entire way they deliver value to the world is with some sort of platform either that they’ve built and housed, which is usually the case. They’ve extended Jenkins, which is really a CI tool, into delivery because they had to. But that’s really the entire way that they deliver value into the world is by being able to take code and get it out with safety and velocity.

    And so, when a company is starting to think about Spinnaker, I mean, that is like doing open heart surgery on a company’s core ability to create value. And Spinnaker is a huge and heavy code base. I mean, it is a big, meaty project. And so, companies need a lot of assistance and best practices and support to be successful with Spinnaker, because it is like open heart surgery for them.

    Now, the good news is that Armory is very, very good at doing this. So, we have the most expertise operationalizing Spinnaker inside complex enterprise environments and making it work within these complex environments of any company. As Netflix once joked with us, they only ever operationalized it once, right? We’ve done it many times.

    We’ve also built a number of features that are enterprise grade to make Spinnaker more consumable and valuable to the enterprise. So, things like being able to install it in an air gap data center environment, or pipelines as code that gets into this GitOps need of being able to create these pipeline definitions and then check them as code to make them reusable and make pipelines more standard across teams.

    So, there’s all sorts of features that we have built in our building that extend Spinnaker for specifically enterprise needs. But most broadly, what we are really doing is, we are championing Spinnaker and helping the enterprise adopt it so that they can become, truly, software first in a very sophisticated, multi-cloud way.

    Shimel: Absolutely.

    DROdio: One other thing that I would mention is really the cultural change that’s required from these large enterprises, which is probably its own separate podcast and conversation, but there’s this thing that we see in these Global 2000 companies, which is that most companies are not very good at managing risk in production in sophisticated ways. And what I mean when I say that is, most of these Industrial Age companies are used to building products or having services that must be perfect in production. When you’re building a car, you can’t have it come off the assembly line and fail right away.

    The kind of cosmic joke is that the slower you are when you’re writing code, the less safe you become, and by moving faster, you actually become safer. But that’s a terrifying cultural concept to these companies that don’t wanna break customer trust or damage brand equity in production.

    A platform like Spinnaker allows them to become much more sophisticated about managing risk in production. So, things like a canary deployment allow companies to not nuke their entire user base when they ship a new feature. They can, instead, limit the blast radius. And so, it’s an important cultural element here to bring a platform like Spinnaker into the company to give, really, the executives and management the kind of license and the trust to start to innovate faster and to move faster in ways that allow them to feel safe, but then become much more sophisticated about the way that they manage risk.

    So, there’s a whole cultural aspect to Spinnaker that is very necessary to give companies these tools that they need to actually undergo this digital transformation.

    Shimel: There’s a cultural aspect to everything with DevOps, even.

    DROdio: Yeah. [Laughter]

    Shimel: But let me—hey, Carl, we’ve been negligent, here. Let’s bring you into the conversation. So, Carl, it’s a unique kind of opportunity. It’s almost a double-edged sword, though, in that, you know, you get to, you’re in charge of marketing what, in essence, is this fantastic platform, Spinnaker, and then, on top of that, what Armory is doing to enhance and make it better for large organizations to adopt Spinnaker—you know, it’s a great opportunity, but it’s a little scary it’s that big.

    As newly appointed or here a few months now VP of Marketing, what do you see as the challenge here in going to market?

    Landers: Sounds like you’ve been living in my office, Alan, the way you just laid that out. But, you know—yes, it’s a big challenge. The way we look at it, though, I think is fairly straightforward. We’re devoting our resources to making Spinnaker a success. As the Spinnaker community grows, as more people are aware and are using and are having success with Spinnaker, the right number will come to Armory for help when they need it.

    And so, as the marketer at Armory, my focus is, the majority of my effort is—how do we make Spinnaker a success? How do we grow awareness and use of Spinnaker so that more organizations are experiencing the benefit? We know that we’ll get our fair share. So, marketing Armory is important, but top of mind for all of us here is making sure Spinnaker is a big success. Does that make sense?

    Shimel: Makes perfect sense. And we would be negligent if we didn’t mention this in that regard that, I guess it was now about six months ago, maybe eight months ago, both Netflix and Google joined what’s called the CDF—Armory as well—joined the CDF, the CD Foundation, which is a sister organization to Cloud Native Computing Foundation, all under the auspices of The Linux Foundation. And, you know, we talk about a community and we talk about making Spinnaker successful—that has to, I guess, play into it.

    How big a role do you see the CDF playing into this, guys?

    DROdio: Carl, I’ll be happy to let you start there and then I can add some color, if you’d like.

    Landers: Sure, happy to. Well, we are a proud member of the CDF along with the other organizations you mentioned, and there are several projects in there, including Jenkins and Jenkins X and Tekton and Spinnaker. And the CDF is forming up nicely and we’re contributing to that foundation and helping it take off, and it is gonna be a great way to help build the community around all of these projects, Alan.

    One of the things that’s gonna be a great addition to the community is, we have a new developer, evangelist, open source leader joining Armory, Dee Kumar. Dee was actually doing this job for the CNCF and for Kubernetes. So, super experienced about how to grow a successful open source community and market effectively, and she did that at the CNCF and is coming over to join Armory on Monday to help us and help the CDF repeat the success of Kubernetes with Spinnaker. So, that’s super exciting.

    Shimel: That’s great. That’s big, that’s big. DROdio, do you want to add—you said you wanted to add a little color?

    DROdio: So, you know, I spend my day talking to Fortune 500 CIOs, CTOs and what I’m really seeing is that DevOps is something that I think executive suites at large companies have considered to be tactical, and it really hasn’t been—it hasn’t risen up to the level where a CIO or CTO or even a VPM just is so focused on it.

    That’s really changing. As companies realize that they must become software first to compete, DevOps is becoming much more strategic, and I believe that CIOs are going to have to own it personally and be very involved in the cultural change that’s required to transform their companies into ones that become very good at getting through the SDLC in minutes instead of months.

    And that’s really why we created Armory. The reason Armory exists is to align very closely with the needs of Global 2000 enterprises that re committed to that transformation and that want to invest in sophisticated, modern platforms like Spinnaker to enable that. We see Spinnaker as powering the core of our platform as we build it. Spinnaker really solves for the delivery challenges that companies have.

    There’s a lot more to the SDLC than just delivery, and so, we are really making a big bet on Spinnaker while having an eye towards the needs of the CIO and solving for all those other blockages in the SDLC that a company has that slow them down.

    So, Spinnaker is just this incredible platform that we’re putting at the core of our strategy and our platform as Armory grows and matures. And the first thing that Carl said is to cement its status as the de facto standard for Cloud Native software delivery. And then also, having all the major cloud vendors contribute and be involved has been a huge step for that as well. So, I think it’s becoming very obvious that, if a company’s really serious about moving workloads into the cloud, Spinnaker is the way to do that at scale.

    Shimel: Excellent. Absolutely. Guys, we’re running low—we’re way over time at this point. I did want to just mention or bring out a few other things, and Carl or DROdio can answer this. In terms of references, we’re talking Fortune 500, we’re talking Global 2000—can you give us some examples of organizations that are using Spinnaker? And if they’re using Armory a well, great, but you know, just to kind of bring home that message of the kind of organizations that are relying on Spinnaker.

    DROdio: Sure. So, on the Spinnaker.io website, which is the project site, there are a number of companies that are publicly listed that are using Spinnaker. Companies like Cisco and Target and Under Armour and Samsung and others. There are actually several hundred enterprises using Spinnaker that are not publicly using it, but are making big bets on Spinnaker. And there are also many enterprises that are using Armory specifically. And so, those include some of the world’s largest technology companies, some of the world’s largest banks, some of the world’s largest health care companies.

    So, we are very dedicated to ensuring their success with Spinnaker. We believe that Armory is the best way for a company to be successful with Spinnaker. But more broadly, we’re also really working hard as deep contributors to the open source project to make Spinnaker very consumable, easy to onboard, easy to self-run POCs and get very quick time to value.

    So, there’s a lot of focus, like Carl said, with the series B in really making Spinnaker easy to try and easy to be successful with as an open source project, and then making it very enterprise grade and bulletproof for enterprises that are putting it at the core of their hybrid and multi-cloud strategies.

    Shimel: Excellent. Excellent, excellent. I know—again, just one more thing and then I’m gonna call it a wrap. There is, as part of CloudNativeCon and KubeCon, there’s a Spinnaker and CDF. Well, there’s both a CDF and I thought a Spinnaker Con coming up in San Diego.

    DROdio: Yeah, Carl, why don’t you talk a bit about that, because I think there’s a few opportunities for people to get involved.

    Landers: Absolutely. So, Alan, I think you’re referring to the Spinnaker Summit which is coming up. It’s going to be collocated with KubeCon in San Diego. It’s taking place on—let’s see if I get the dates right—November 16th and 17th, so over that weekend, and then KubeCon starts on the Monday, Tuesday following. So, it’s gonna be a huge Cloud Native fest in San Diego.

    We were just reviewing the CFP, the proposals that came in today. There were, oh, 80 or 90 sessions submitted from amazing companies to speak at the summit, and we’re just going through right now and picking the best ones to actually put on the agenda. It’s gonna be a great event and information is available from the Spinnaker.io website. You can get there and learn all about the Spinnaker Summit. Thanks for the plug.

    Shimel: Absolutely. And you know what, when it’s live, we’ll try to get some announcement—when the CFP is live, we’ll get an announcement out.

    DROdio: And, hey, Alan? We haven’t talked about this yet; Carl, we haven’t talked about this yet, but why don’t we just go ahead and offer something up, here, because we do have a culture of defaulting to action.

    Why don’t we create a discount code for anybody who’s listening to this podcast and would like to attend the Spinnaker Summit and maybe we can make it DevOps.com or something like that—

    Shimel: Fantastic.

    DROdio: – and Armory will provide a bit of a discount for anybody who would like to attend to help anybody who’s listening convince their manager that it’s something worth going to. So, I don’t know how much of a discount we can provide, but I’m happy to commit to doing something.

    Landers: Absolutely.

    Shimel: Thank you very much, DROdio. And you know what, for listeners—take advantage of it. Guys, what I’ll try to do—Carl, if you can get me the details and the code, I’ll include that in the show notes for the podcast, and anyone listening to this can go check it out there as well as, it’ll be in the DevOps.com article for it, as well.

    DROdio: Perfect.

    Landers: Sounds good. I’ve got DROdio’s credit card number coming over to you.

    DROdio: That’s right. [Laughter]

    Shimel: [Laughter] Fantastic!

    DROdio: And then, also, for anybody who would like to learn more about Spinnaker, there is a Slack workspace, and I would highly recommend that anybody check that out. You can get to it on the Spinnaker website, but you can also just go to Join.Spinnaker.io and enter your e-mail address and then you’ll be in that community.

    There’s over 7,000 people in there, and it’s a very active community. We are very active in there, as is Netflix and Google and many others. And if you—you know, it’s a very friendly community, so if anybody would really like to ask questions, don’t be afraid to ask any newbie questions in there, we’ll be happy to answer them.

    Shimel: Fantastic. Guys, I gotta tell you, this was the longest 15-minute interview I’ve ever done.

    DROdio: [Laughter] And yet the shortest at the same time, feels like. [Laughter]

    Shimel: Yeah. I told you, it goes quick. I apologize, but you know what, I think it was well worthwhile. First of all, guys—congratulations on the series B. You know what? In today’s world, it seems every day some company’s announcing funding, but there’s a lot of entrepreneurs out there, and DROdio, you know this, right, who never get to raise money.

    DROdio: Yeah.

    Shimel: They try and try and try and they just can’t get it done. And the fact that you guys are doing it is a testament to both Spinnaker and Armory’s plan as well as what you’re doing, so, congratulations—and to you guys individually—so, congratulations and success.

    And then, secondly, we’re excited to see Spinnaker take its place in the CD universe, here.

    DROdio: Yeah, likewise. Thank you for the support, Alan, as well.

    Shimel: My pleasure.

    Landers: Thank you, Alan.

    Shimel: Hey, alright—DROdio and Carl Landers from Armory announcing their series B, and it’s all about Spinnaker and Armory here today. This is Alan Shimel for DevOps.com, and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • GitLab Research Reveals DevOps and Cybersecurity Disconnects

    GitLab Research Reveals DevOps and Cybersecurity Disconnects

    DevOps and cybersecurity teams have a complicated relationship, which impacts code quality, research shows

    Finger-pointing has long been the name of the game when it comes to cybersecurity failures. After all, who should be responsible when so-called bad code or bad practices are blamed for the latest incident? 

    A recent survey by DevOps lifecycle tool company GitLab reveals a significant disconnect between application developers and cybersecurity professionals—a disconnect that could only lead to more security woes and additional finger-pointing. GitLab surveyed more than 4,000 app development and cybersecurity professionals and brought some light to the complicated relationship between both. 

    For example, some 49% of the cybersecurity professionals surveyed claimed they struggle to get developers to make the remediation of vulnerabilities a priority. Sixty-eight percent of those same security professionals believe less than half of the developers they work with can identify security vulnerabilities before new code moves into the test cycle. 

    While cybersecurity professionals like to point the finger at the developer community, there are two sides to the survey. Almost 70% of the developers surveyed said that while they are expected to create secure code, they get little help or guidance from the cybersecurity experts with whom they work. Perhaps the fault lies with the lack of mechanisms to make cybersecurity a priority in many organizations. “We don’t have clear guidelines about security, so the different services present different levels of security,” noted one developer in the report.

    While developers and cybersecurity professionals may be at odds, the report also revealed there is plenty of additional blame to go around. Case in point is the revelation that many organizations don’t make cybersecurity a priority. Some 44% of those surveyed reported they are not judged on security vulnerabilities in their code. That creates an environment where developers don’t have to consider cybersecurity issues when writing code.

    With developers, cybersecurity professionals and even the companies they work for all at odds about the responsibilities of proper cybersecurity hygiene, one has to wonder how tomorrow’s vulnerabilities will be prevented.

    “Our research tells us that while most developers are aware of the dangers that vulnerabilities present and want to dramatically improve their security capabilities, they often still lack organizational support for prioritizing secure code creation, increasing secure coding skills and implementing automated scanning and testing tooling to make that happen sooner rather than later,” said Colin Fletcher, GitLab’s manager of market research and customer insights.

    Solving the blind spots around cybersecurity is going to take a different approach, one that further tears down the silos created around cybersecurity teams and development teams. There is a little bit of irony in that observation; after all, DevOps is all about tearing down silos and creating functional teams. 

    It’s also an irony not lost on those at GitLab. The company promotes solving the cybersecurity issues by adopting a good DevOps practice, where cybersecurity becomes an integral part of the DevOps process. According to GitLab, incorporating cybersecurity into DevOps will have the positive result of the combined team being three times more likely to discover security bugs before code is merged into operations.

    The report offers some significant conclusions that support GitLab’s claims. For example, some of the security top findings include:

    • Sec teams are three times more likely to discover bugs before code is merged with a good DevOps practice in place, and are 90% more likely to test between 91% and 100% of code than in an organization with early-stage DevOps.  
    • Nearly half of security pros surveyed (49%) said they struggle to get developers to make remediation of vulnerabilities a priority.
    • Half of security professionals said bugs were most often found by them after code is merged in a test environment.  
    • Mostly remote teams are 23% more likely to have mature security practices than primarily office-based teams.
    • Only 44% report security vulnerabilities are a performance metric for developers in their organizations.

    GitLab also revealed there is another consideration, one of ownership. According to the report: 

    No part of software development raises more issues about ownership than the subject of security. The idea that everyone is responsible for security might be the ideal but it can also be part of the problem as everyone can easily turn into no one. Security professionals often complain about being on the outside, while developers and operations teams can resent being told how to prioritize their work. Our survey responses indicate developers are taking more responsibility for security, but of course a lot of work remains. In fact, only 20% of those surveyed rated their organization’s security efforts as good, while 36% said they were fair and 24% said they were poor.

    — Frank Ohlhorst

  • 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