Author: Alan Shimel

  • DevOps Chat: ASG State of Software Delivery Management Report

    DevOps Chat: ASG State of Software Delivery Management Report

    Accelerated Strategies Group has just delivered its “State of Software Delivery Management Report,” commissioned by CloudBees. In this DevOps Chat, we speak with Mitchell Ashley, CEO, founder of ASG, about the report and why it is important for everyone managing software delivery today.

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

    Transcript

    Alan Shimel: Hey, everyone. This is Alan Shimel, and you’re listening to another DevOps Chat. I have a really great chat lined up for us today because I’m joined by my partner, Mitchell Ashley, founder, CEO of Accelerated Strategies Group. Mitchell, welcome to another DevOps Chat.

    Mitchell Ashley: Well, very nice to be here. It’s great to be on this side of the microphone for a change. [Laughs]

    Shimel: It is kind of. I mean, Mitchell, before we jump into the report out of Accelerated Strategies Group we want to talk about, just as little history for our audience. Mitchell and I have been doing podcasts together now –

    Ashley: Oh my.

    Shimel: Fifteen years?

    Ashley: At least. 2004 or ’05, something like that. Yeah.

    Shimel: So it’s still secure after all these years.

    Ashley: I was waiting for the,”This is Alan Shimel and this is Mitchell Ashley.” [Laughs]

    Shimel: Exactly. Do you remember those days? Oh my goodness. You know what’s old’s new. It’s good to have you on with me, Mitchell. You know, as you said you’re often on this side. You and I kind of split up our hosting duties for DevOps Chat. But we’re here today because Accelerated Strategies Group just dropped a report on the state of software delivery management, SDM.

    Ashley: We did.

    Shimel: And the report was commissioned by our friends at CloudBees but it really is the independent analysis and research of you, Sanjeev Sharma, principal analyst at Accelerated Strategies Group, and the rest of the Accelerated Strategies team. So, you know, we’ve done a little video on this, Mitchell, but I’m going to assume our audience listening here on DevOps Chat maybe didn’t see the video.

    Ashley: Okay.

    Shimel: Why don’t we start off – when we talk about SDM, what are we talking about here?

    Ashley: You know, we used to – we’ve had all kinds of names for methodologies, you know, software development lifecycle management, blah, blah, blah. You know, what I think it’s really about, software delivery management is about the whole delivery, the end-to-end process of how do you manage the software process from here’s money, we’re going to invest in something that we think is going to be created through software; how do you know through the whole machinations it goes through to actually create the software that you know where you are and what you think you’re going to be getting? And then when it’s all done how do you know that you got what you thought you paid for? To think about is sort of as a business view into managing the software process.

    So not just IT and product teams but also the executives, senior leaders, can find out what the heck is going on and how well – it’s really about how well do we develop software and how well – our ability to manage it.

    Shimel: Yeah. I agree. You know, we had this discussion earlier with Sanjeev as well, correct, and, you know, in my mind it’s about how do we manage the factory rather than how do we work on the assembly line? A lot of software today, especially in the DevOps world, is about how do we work on the assembly line? And that’s a noble, worthy thing to do.

    Ashley: It’s important, yeah.

    Shimel: Right. That software delivery pipeline, that factory, you know, assembly line as we move software left to right. But, you know, someone needs to be managing the controls, right? And are we doing it just in time? Are we using lean? And if so, how? You know, even lean you always need to be turning a dial and checking things out.

    Ashley: Exactly.

    Shimel: I’d like to talk a little bit, Mitchell – well, let me – let’s first start with this.

    Ashley: Sure.

    Shimel: Of course the mantra at Accelerated Strategies is information wants to be free, and in that vein this report is free and open to anyone – anyone – who’d like to download it, right?

    Ashley: It is. That’s our belief. I mean that’s really what we founded and you were part of founding Accelerated Strategies group two, is let’s do something disruptive in the analyst industry. You and I have paid an awful lot of money to analysts for sometimes questionable [laughs] – what are we getting for it? – but we have to do it, right?

    Shimel: Well we paid for access.

    Ashley: We paid for access even though that’s – you know, everyone says it’s not true –

    Shimel: [Inaudible comment]

    Ashley: – but it is. I mean let’s be honest about it. I think it is anyway. With Accelerated we said, “Look, we’re not going to pay –” you know, every time you touch an analyst you had to pay him. Every time you said something to him you’re like dropping in another coin. And let’s do this the right way. Let’s do this – when you’re working with us, engaging us to do something for you, you know, do some research, assess the market, advise you, do a strategic project, do some competitive analysis, all of those things for a research report, that’s when we’ll make our money. You are welcome to distribute that as freely as you like.

    We’re not going to hold you behind a paywall and subscription fees and licensing. The customer’s give us all that information. Why don’t we give it back to them in some meaningful way [laughs] instead of making them pay for it? That’s –

    Shimel: You know what, Mitchell? I think back to the days where we would pay, you know, a certain large analyst company to send an analyst out to spend the day with us, and we’d pick them up at the airport and get them breakfast and lunch and, you know, keep – wine and dine them all day while trying to get him to understand our point of view, and when I drop him back off at the airport, I’ll be honest with you, I felt a little dirty.

    [Laughter]

    Ashley: And it kind of felt like, why do I feel like we know more about this space than the analyst?

    Shimel: Yeah, there was no doubt that I felt like I knew more about that space, but, you know – and I’m not – look, everybody needs to make a living and there’s the oldest professions in the world, but I really felt like I – I didn’t like paying for it. You know what I mean? And there was definitely some of that involved. But enough about the analysts. _____.

    Ashley: We could do, like, three podcast episodes on that or more.

    Shimel: Yeah. We can go off on that. What I want you to talk about though, Mitchell, is would you share with our audience a little bit of insight? How was the research done here, the analysis? I know Sanjeev Sharma, principle analyst, was lead author on this report, but give us an idea of, you know, the ASG methodology, if you will.

    Ashley: Well really any research has to start out with some hypothesis; what do we believe about the market or what do you think we believe about the market? And really the hypothesis here was around what’s the maturity level of our ability to manage the entire software delivery process? Connecting it to the business, not just inside of IT. So we started with that and we have a target audience who we’re trying to talk with, both individual contributors, leaders in the software development part of this but also executives, product people, CIOs. So we really tried to cast a big enough net but not so broad that it all got watered down and you couldn’t tell who said what.

    We really spent some time focusing on who we wanted to talk to. And it wasn’t a short survey but it wasn’t a long one. There were really some insightful questions around do you know what your backlog looks like and what it costs you to delay a release or to trade something off one feature for another? Do you really know when you’re going to get the release or the functionality that you’re paying for so you can move the business forward based on those plans, or are you kind of shooting in the dark and you’re just hoping that it comes out sometime in the next quarter and we’re good and then we’ll kind of get everything running from there? So we did a survey, but we did a lot of kind of research going into it, talking to different people in those roles before we ever built the questionnaire.

    So it’s not just a research firm that says, “Okay, what do you want us to ask? Let’s build you a survey.” You know, Sanjeev and the other analysts with Accelerated Strategies Group are all practitioners. They’ve done this, they’ve worked in this field, they’ve led software teams, projects, companies, they’ve consulted with big enterprises, small startups, medium-size companies. So all that to say it was really, you know, our best attempt at let’s get the best information we can when we go out and ask people for where they think they are with their maturity curve and where they really see the challenges, and we got some fantastic results. It was super, super insightful and kind of exciting to see, you know, what things we thought were true and what maybe some things were, hm, that’s a little bit of a surprise.

    Shimel: Yeah. Okay. I guess you kind of opened that box now.

    Ashley: Did I set it up well enough?

    Shimel: Yeah. I think you got it. So let’s start with the surprises.

    Ashley: You know, so one of the biggest things that everyone – I don’t want to say everyone – one of the biggest outcomes of this research was around everyone’s ability to understand the value they’re going to get from their investment, right? Spending how much money on this software IT organization, product team whatever, and what am I really going to get at the end? So it’s very clear it’s very unclear to the people funding the work, that they essentially understand what they’re going to get. You just can’t get to that information or get a straight answer.

    We aren’t connected well enough into it to really understand it, which kind of goes to the second key finding was the communications around the whole software creation process is broken. It may work within a development team that’s really functioning tightly together or an Agile team with a product leader that they’re working with day to day, but outside of that, both kind of horizontally but also vertically in the organization, the perception at senior leader levels versus the individual and the team levels that are building software can be much, much different. So can you imagine making – well, we’ve done this right, Alan? – making multimillion, maybe much, much, much larger decisions based on what you think is going on and that’s not really true.

    So that’s a huge issue. If we really believe in software is leading the world, that all businesses are software companies, you have to be – you’ve got to fix that. That’s got to be taken care of. And then the third area is basically all the way through the delivery pipeline and understanding the value flow. Where are you creating value and where are you actually spending energy and not getting value? Maybe getting the wrong output out of the software process. Because an example I like to use is software teams like to measure how many releases we get out per day, sometimes per hour. I mean that’s a great thing. It sounds like a really awesome thing to accomplish. But if it’s the wrong thing, wrong software, it doesn’t matter if we’re releasing it a million times an hour. I’ll take one release a month if it’s the right thing instead of a million releases every day and all of them aren’t hitting the mark.

    Shimel: Yeah, I agree.

    Ashley: That’s an extreme, but that’s really what it is, is understanding through that whole – and again, we’re talking about not one pipeline of work, one value stream of work; it’s across multiple, because almost every app touches all kinds of systems, data, you know, especially in a large enterprise – mainframe, stuff in the cloud, stuff that’s maybe kind of the older client server but still around, whatever it might be. So those are the three key areas that we identified that if you can assess where you are and how well you do that part of the software development, that will make the biggest difference in sort of upping your game and your ability to deliver software.

    Shimel: Agreed. Agreed. You know, I guess I’m not surprised but I am surprised in that, you know, the first thing I learned about DevOps was it’s about breaking down silos, bringing dev and ops together. We’re going to break those silos. Kind of like the Macintosh 1984 commercial, remember?

    Ashley: [Laughs] The girl and the hammer, yeah.

  • DevOps Chat: Software-Defined Storage, With StorPool

    DevOps Chat: Software-Defined Storage, With StorPool

    The whole Data/DataOps space is becoming very hot. For StorPool, it is more of a case of the rest of the world catching up to what the company has been doing for a while now. It is the leading distributed block storage provider globally.

    In this DevOps Chat, we speak with Boyan Krosnov, co-founder and chief of product at StorPool. Boyan gives us the background on StorPool as well as a good look at the state of the distributed storage/data market.

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

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel. You’re listening to a DevOps Chat here on devopsy.kinsta.cloud, and my guest in this DevOps Chat is Boyan Krosnov from StorPool.

    Boyan Krosnov: Hi, Alan.

    Shimel: Boyan, I know it’s not perfect, but it’s the best I could do with your name, I apologize. But why don’t you say it for our audience?

    Krosnov: Sorry—repeat, please? I did not hear.

    Shimel: Why don’t you say your name for our audience?

    Krosnov: Yeah, so, my name is Boyan—Boyan Krosnov, but in, kind of for English speakers, most people say Boyan Krosnov, like, with the stresses at the wrong places, but it’s perfectly okay, you know, I understand.

    Shimel: As long as they don’t call you late for dinner, as we say here, right?

    Krosnov: Yeah, okay.

    Shimel: So, Boyan, your company is StorPool, yes?

    Krosnov: Yeah.

    Shimel: And what’s your position with StorPool?

    Krosnov: In StorPool, I am one of the Co-founders, one of the three Founders in the company, and my role as a Co-founder from the very beginning has been kind of the glue between technology and business and the product person in the company, the Chief of Product of StorPool.

    Shimel: Sure.

    Krosnov: And the other two Co-founders, you know, respectively take, are focused on technology development and the other Co-founder on strictly business, who is our CEO, right.

    Shimel: Someone has to do that. Okay.

    Krosnov: Someone has to do the business stuff, yes.

    Shimel: Someone has to. Before we jump in, Boyan, to what StorPool is about and what you guys do, why don’t we talk a little bit about your own personal journey? How did you come to found StorPool? What’s your background?

    Krosnov: Yeah, right. So, back in the ‘90s, I used to do competitive programming, so like, from a fairly early age, I got very interested in informatics or computer science, right? And from that, later on, I went into networking and ISPs, later on, I had a startup around something called packet processing and nowadays software-defined networking.

    And from that, at the later stages of that startup before we folded that, we found this gem of an idea of software-defined storage before it was called software-defined storage, right? So, we didn’t know it was called software-defined storage; the term wasn’t coined yet. That’s, like, in 2011.

    Shimel: Mm-hmm.

    Krosnov: And, from that, we founded StorPool. So, I got with the other founders and did, like, a whiteboard exercise of what an ideal storage system would look like. And that became the architecture of our product afterwards and we’ve been building on that for the last years, right? It’s eight years now.

    Shimel: Yeah.

    Krosnov: And along the way, we got—yeah, so, I’ve lived in a few places, not just in Bulgaria. I’ve lived in Iceland and the U.K. and Malaysia and a few others. And so, in StorPool, you know, we started with the idea, implemented it, got it to first production use some five, six years ago, right, and since then, we’ve been expanding it in a very kind of real business organic way, meaning pretty high growth, but at the same time, very customer-oriented. So, it’s very—the things we build into the product are things that our customers demand, right? It’s not like a completely greenfield.

    Shimel: Yeah, everyone already has some data.

    Krosnov: We do stuff that matters for our customers, right?

    Shimel: So, Boyan, listening to your story, I’m reminded of my own. You know, I got into technology in the mid-‘90s when the web first started coming in, it was just starting to get commercial, and we were storing websites. It wasn’t called hosting. I thought I was a virtual real estate person, [Laughter] because as I needed more land, I put another hard drive in the machine, right?

    Krosnov: Yeah.

    Shimel: And by about 1997, people started calling that web hosting.

    Krosnov: Yeah.

    Shimel: And we sold the company in 1998, we ended up doing a whole IPO and that whole thing. But, you know, at the end of the day, what we were doing is, we were just, we were storing people’s websites. I was selling virtual real estate, renting virtual real estate out. And it sounds like a similar thing you, before there was a thing called software-defined storage, you recognized that there was a need in the market for people to do, to be able to store stuff without the expensive, I mean, you know, back—I remember in those days buying EMC boxes, right?

    Krosnov: Yeah, yeah.

    Shimel: And some of the Sun and IBM—was it IBM Sharp? I forget. But all of these huge SAN—you remember the days.

    Krosnov: Yeah.

    Shimel: Millions—millions of dollars in SANs and all of that. And then, [Snaps fingers] it was like a flip—like a switch flipped. People started saying, “Wait a second, we could do this in software, for a lot less money with a lot more advantages.”

    Krosnov: Yeah, yeah.

    Shimel: And it sounds like StorPool happened to be right there at the right time when this was coming together.

    Krosnov: Yep, so, kind of the reason we started it was a few conversations with, actually, hosting companies.

    Shimel: Really?

    Krosnov: Actually hosting companies and some banks, but it started with hosting companies, and at that time, there was this big movement in hosting—everyone wanted to be the next DigitalOcean, right?

    Shimel: Right.

    Krosnov: Everyone wanted to have, like, a public cloud service with virtual machines and be like Amazon and DigitalOcean. And there were architects in these companies that were trying to figure out how to do it and they couldn’t and the one piece that was missing was software-defined storage. It was, like—they couldn’t make the business model work with standard SAN from HP or IBM or EMC, right? And we had to find a solution that worked for them which runs on standard servers—like, it’s not a proprietary box.

    Shimel: Understood, understood. So—I mean, but that was 2012. Now, here we are, 2020. Software-defined storage is a much better-understood term.

    Krosnov: Mm-hmm.

    Shimel: You know, I think it’s gone mainstream, if you will, right? People understand it and use that.

    Krosnov: Yeah.

  • Google Exposes Old Wounds in Open Source Community

    Google Exposes Old Wounds in Open Source Community

    Things boiled over a bit last week with the announcement that Google launched the Open Usage Commons (OUC) consortium (see Mike Vizard’s article here). The announcement and subsequent angst it has caused has upset what had been a pretty stable environment that helped open source software become the dominant force in development and IT. While on its face OUC is about trademarks and usage guidelines, but make no mistake: This is about Google (and perhaps others) disagreeing with the management and direction of The Linux Foundation/Cloud Native Computing Foundation (CNCF).

    Hand-in-hand with the OUC, Google also announced it was making changes in the board composition of the Istio project. A new formula based on code contributed by companies, as well as community seats selected by the community of other contributors, would determine who governs the project.

    Together, this represents a clear bifurcation of managing the code of a project and the trademarks/IP of the project. This is not a new concept in open source, but in recent years has been seldom used. In probably the most famous example of this setup, Linus Torvalds controls a company that still owns the Linux mark, which the Linux Foundation manages it for him. It is separate from the Linux project itself, though.

    The concept of the code being open and free while the project owners retaining the IP and trademarks was very much the norm in open source years ago. However, it led to many companies’ reluctance to contribute code to projects for which they had no say in the governance or usage of the marks. One of the benefits of the foundations such as CNCF, Cloud Foundry, Eclipse and others was that under their model, everyone had access to the same code base and mark usage rules. What you did on top of that was up to you. Ironically, this is the same argument we are hearing now regarding the changes to the Istio governing board and the OUC.

    Perusing the Twittersphere on this subject turns up a few other issues that may be at play here:

    • The CNCF and the Linux Foundation, by implication, may be a victim of its own success. The amount of money they have generated and their “marketing” profile seems to have turned some people off.
    • The CNCF/Linux Foundation model of allowing major corporate contributors to, in essence, buy board seats and having just a minority of “at large” seats open to the community favors the big, rich vendors over the rest of the pack.
    • New leadership at Google and Google Cloud are having second thoughts about turning over the fruits of their work to foundations that they eventually lose control over. Recent former Oracle management is being rumored behind this, though that is not confirmed. In this scenario, second doubts about Kubernetes and other Google-donated projects that are now out in the market without a Google edge are causing them to rethink their approach.
    • Companies that rely on these open source projects and historically are decent corporate members, such as IBM, have been caught in the open here as evidenced by their reaction to the Istio affair.

    What I do know is that the loser in all of this will be the community. Open source works best when there are stability and predictability over its future and governance. The broader the base of management and ownership of a project, the more willing corporate contributors are to participate and contribute. I would hate to see us return to the maze of the Cathedral and the Bazaar. I sincerely hope we are not seeing the end of the golden age of open source software.

  • Digital Anarchist – Watch What’s Next in Tech

    Digital Anarchist – Watch What’s Next in Tech

    Today, we announce the launch of the next version of Digital Anarchist, our next-generation video platform, at digitalanarchist.com. The content is also available on the devopsy.kinsta.cloud mobile app and OTT channels on Apple TV, Roku and Amazon Fire TV.

    Boasting more than 1,400 videos and featuring 1,000-plus guests, the Digital Anarchist library may be the single largest collection of videos covering topics related to DevOps, cyber, cloud-native and digital transformation. It includes webinars from across the MediaOps properties, virtual event sessions, interviews from conferences around the world, DevOps Chats and more.

    The new interface, video recommendations and searchable guest and video index are more closely aligned with the original vision of Digital Anarchist that John Willis and I had when we came up with the concept. Providing a consistent user experience across different platforms and applications has proven to be a challenge. We continue to work at it.

    The No. 1 Source for IT News and Entertainment

    Digital Anarchist is a hub with thousands of hours of information, serving as a catalyst for digital transformation that disrupts the outdated and inefficient, providing the information organizations need for a faster, higher-quality and more secure future.

    Visitors and subscribers will have access to exclusive live and on-demand content from a variety of channels:

    • Virtual Events – Catch up on sessions and one-on-one interviews with industry leaders from more than a dozen conferences and virtual events hosted in the last 12 months. 
    • Analyst Corner – View weekly segments hosted by Accelerated Strategies Group’s analysts and seasoned industry veterans, covering the latest trends and opportunities for businesses during these unprecedented times.
    • TechStrong TV – Live-stream TechStrong TV on Digital Anarchist three days a week or access previous episodes to hear honest and open dialogues with tech leaders and executives covering the latest news. 
    • DevOps Chats – Hear the latest episodes of “fireside” podcasts featuring devopsy.kinsta.cloud and Security Boulevard Editor in Chief Alan Shimel and Accelerated Strategies Group CEO Mitch Ashley, as they chat with luminaries and thought leaders in DevOps and security.
    • On-Demand Webinars – Replay webinars from devopsy.kinsta.cloud, Security Boulevard and Container Journal 30 days after the live event.
    • CISO Talks – Join MediaOps CEO Alan Shimel and Unisys CISO Mathew Newfield in a bi-weekly series to explore the latest in cyberspace, featuring other experts and newsmakers in the field.
    • DevOps Unbound – This bi-weekly/monthly roundtable, sponsored by Tricentis, provides a deep-dive into DevOps, with an emphasis on continuous testing and automation. Roundtables will be open to audience interaction as well.

    State-of-the-Art Studio and Video Production

    Digital Anarchist features both original and third-party content. The streaming service also provides video production, distribution and sponsorship, offering opportunities for both branding and lead generation campaigns.

    Using state-of-the-art digital HD equipment and dynamic post-production video editing, the Digital Anarchist team is highly qualified to create custom videos to tell your story and reach a global audience. Some of Digital Anarchist’s services include:

    • Educational series.
    • Case studies.
    • Brand marketing videos.
    • Storytelling testimonials.
    • Sponsored ads.

    If you would like to have your video content featured on Digital Anarchist, reach out to us at sales@mediaops.com.

    In the meantime, please check out the new site and subscribe if you’d like to be the first to see the 15 to 20 new videos we add on a weekly basis. And, as always, your feedback is welcome.

  • DevOps Chats: Easing WFH with strongDM

    DevOps Chats: Easing WFH with strongDM

    strongDM wasn’t founded to help with remote workers forced out of the office by COVID-19. They have been around for five years now. But, the company does excel at allowing you to manage and audit remote access to all of your assets including DBs, servers and clusters (as well as apps and services) anywhere from anywhere.

    In this DevOps Chat we speak with strongDM Justin McCarthy, CTO and co-founder about how the company’s technology works and how it is helping companies move to remote access given current conditions.

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

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel, and you’re listening to another DevOps Chat.

    Really happy to be joined on this chat by Justin McCarthy of strongDM. Hey, Justin, welcome to DevOps Chat.

    Justin McCarthy: Hey, Alan — thanks.

    Shimel: Pleasure to have you on here, Justin. You know, as we were talking a little bit off mic, I don’t know if we’ve introduced our MediaOps community, meaning DevOps and Security Boulevard and Container Journal, we haven’t introduced strongDM to them before. So, why don’t we start with that, Justin, and if you wouldn’t mind, in telling the story, talk about a little bit about your own personal journey.

    McCarthy: Yeah, sure thing. Alright, so, first, I guess I’ll just briefly introduce myself. So, I’m the co-founder and CTO of strongDM. And the product is actually, strongDM itself is the best way to manage and audit remote access to your servers and databases and really even Kubernetes clusters. So, that’s what we focus on. We are a remote access product.

    And the way we came to it is basically just a sort of typical startup story. We’ve been around for five years now, and at the beginning, it was scratching an itch just like so many other infrastructure and DevOps products out there. So, in my career, I’d always been involved in growing the teams that built the product and, inevitably, when you build a product and when you ship and when you have production data, you need to grant access to it. To analyze it, you need to grant access to it to administer it, to debug it.

    And that process always felt a little bit somewhere between inconvenient and scary, right? [Laughter] And so, basically, strongDM — yeah, is the response to all those feelings of, that it wasn’t quite as smooth as it could be, it wasn’t quite as safe as it could be.

    Shimel: Excellent, excellent. And you mentioned the company’s around now about five years.

    McCarthy: Mm-hmm.

    Shimel: That’s cool. Alright, let’s talk about — and you’re right, a lot of companies do grow out of one particular scratch to itch, and I’ve done my share of startups over the last 25 years. And what generally happens is, you find out that that particular itch may have associated itches, right, and there’s ancillary things — well, once I scratch that itch, the next itch pops up, right? To paraphrase “The Phoenix Project” or something and bottlenecks and the goal.

    Talk to us—what’s the itch, and then what have you guys found over the five years about kinda getting to that itch and associated itches?

    McCarthy: Yeah, yeah, definitely. So, at the core, the technical approach that it probably takes is that we are an identity-ware proxy, okay? And the first application of that was for database access. So, that’s where we started, right?

    Shimel: Mm-hmm.

    McCarthy: And in fact, at the beginning of time, we thought maybe that was all there was to it. But as we —

    Shimel: Hold on a second, though.

    McCarthy: Yeah, sure.

    Shimel: So, an identity-ware proxy, primarily for databases. For some of our audiences — our security … actually, our DevOps audience probably gets that, some of our security folks do. But break it down for me, Justin — what exactly do you mean by that?

    McCarthy: Sure thing. So, this is an architecture that I think a lot of folks might know as Zero Trust, a lot of folks might know as BeyondCorp, and there were a lot of examples of it out there in sort of an HTTP only case. When we originally conceived of and built the product, it was kind of even prior to a lot of that nomenclature existing.

    So, what an identity-ware proxy is, it is a proxy for a given type of service. Let’s continue to use databases as the example. So, if somebody needs to interact with a Postgres database or a Microsoft SQL Server database — so, let’s say Alan needs to connect your local copy of Tableau to one of those systems, right? So, Alan would log into strongDM and then strongDM would then conduct all of the traffic, essentially, forward it to the target systems. And the identity-ware aspect is that, essentially, we know it’s Alan the whole time and we’re proxying that traffic and we’re handling, essentially, all of the routing of that traffic.

    Shimel: Got it.

    McCarthy: And what’s interesting about that is that you kind of get a lot of the sort of — you get a separation of sort of Alan’s identity from, you know, the credentialing of the underlying system. So, you can actually credential that separately, which means you can rotate the underlying credentials without bothering Alan.

    Shimel: Now, in and of itself, can that be a security kinda setting up kinda almost a man in the middle type of situation?

    McCarthy: Yeah, so, in a lot of enterprises and environments, you at some point, you have to answer the question, how are we gonna audit this particular traffic stream, right? And so, there are also a lot of products out there that are dedicated to, for example, breaking TLS, right? Being the official man in the middle, right?

    Shimel: Yep.

    McCarthy: So, our product has an element of that built in, although it’s not a generic TLS breaker. What it is, is it’s a protocol specific way to answer the question, you know, given MySQL database selection, what would you want to know about what Alan did yesterday? And so, our product is focused on extracting that kind of rich information about what Alan did yesterday with respect to this MySQL connection.

    Shimel: Sure — great, great. Now, what made databases sort of, you know, the prime example of where to use this or as the first use case?

    McCarthy: Yeah, it was the first use case, largely because, again, we were scratching our own itch. [Laughter] So, that was the one that I most often encountered.

    Shimel: Okay.

    McCarthy: You know, and the appeal is, it’s phrased as, you know, “Can I please have access to this because I need to debug X?” Right? And that always, whoever is saying yes or maybe or no to that request, you know, there’s a lot of hope and trust that when you say yes it’s gonna be okay. So, what our product does is, it takes all that, the sort of emotions around that event [Laughter] and tries to give you an answer for how you make that convenient and how you make that safe for everyone.

    Shimel: Excellent, man — good. Alright. So, first ditch is the database and we figure that out and go from there, Justin.

    McCarthy: Sure. So, as I’m sure, as you found with many products, you know, why adopt 10 different products when you can get your existing vendor to do one more thing for you and then maybe reduce and concentrate more of your attention on one tool and so, that’s where our customers pushed us. And so, the next very strong demand that we saw was, now that all of our data systems are granted and revoked access through strongDM, could you also begin to do some of the interactive session and shell-based protocols? So, the first two there were obviously SSH and Windows Remote Desktop. So, that’s where we went next.

    And the theme, if you can sort of imagine it is, you know, everyone in my organization that maybe has engineer in their title or even analyst or scientist — essentially, all of those folks, they need more than just webpages to do their job, right?

    Shimel: They do.

    McCarthy: And so, if it were just webpages, then existing single sign-on would work great, right? But since it’s more than that, it’s deeper than that, it’s really that whole collection of use cases that our customers began asking us to take on.

    Shimel: Excellent. Good stuff. And so, let’s talk a little bit about — so, how, is this sort of distributed as a SaaS kind of thing or a web-based kinda interface? How does that work?

    McCarthy: Sure, yeah. I would say we are neither traditional SaaS, nor traditional on prem. So, in terms of how the product deploys, our customers end up running a bunch of it, but not all of it. So, with any system that involves credentials, any system that involves cryptography, operating it successfully and carefully is actually a huge part of getting it right, okay?

    Shimel: Mm-hmm.

    McCarthy: So, what we’ve tried to do is, we’ve tried to unify the sort of operation configuration. So, if you think of it like centralizing the policies, centralizing the key management.

    Shimel: Yeah.

    McCarthy: So, that’s the part that we host. But the part that actually runs the proxies and therefore essentially the actual conduits for all the data, that runs entirely in customer environments.

    Shimel: And what kind of environment are you talking about?

    McCarthy: Yeah, so, I would say our average customer, the answer is, like, several. [Laughter] So, there are very few environments where you have just one cloud, where you have just one prem data center. So, it ends up actually being several. And so, that’s another strength of our architecture and our approach is that our product, from day zero, was designed with that in mind, so you can run our proxies in Azure and in AWS and in your existing legacy data center. They all unify into one sort of access plane, and it doesn’t matter the product. The same grant access gesture applies to all of those environments.

    Shimel: Oh, okay. Very cool. Very cool. And, you know, from what you’re describing, to me, it doesn’t really make a difference whether I’m a cloud native company, let’s call it, right, or maybe an old line company that had my database running in the closet, right? This kind of identity by proxy is still something I can utilize to make my life easier.

    McCarthy: Yeah, absolutely. And of course, we would hope that it’s especially suited to a hybrid environment like that, because the ability to, from an end user point of view, from one of your data scientists, they just know the three logical things they need to access to do their job. They definitely don’t care what cloud it’s hosted in. They don’t care what data center it’s hosted in, but from the point of view of that end user, it just looks like one thing.

    Shimel: Okay. Now, let’s look at it from the lens of COVID, which we kinda always have to look at everything today through this lens — it seems like this would be a help, right, if I just had to move my whole workforce home, you know, remote. What have you guys been seeing on that?

    McCarthy: Yeah, I think our story there is pretty similar to what a lot of companies that are part of the sort of next generation of IT and — we’re sort of seeing the same trend that everybody else, more people moving remove, therefore any remote access products are, there’s a lot more interest at the moment.

    So, we were always about granting access remotely. It was always a workforce that was going to be distributed. That was our typical customer, anyway. So, it’s definitely the same theme, but just more than we were seeing pre-COVID.

    Shimel: Excellent, man. Now, one thing — it’s funny, I just had a conversation with another company within the IDM space, kind of in like an ED directory service, let’s call it, and this popped up. With the people working from home, with the explosion of how many apps and SaaS services, you know, we’re all accessing right now, it’s great to be able to have just a single proxy, if you will. So, I only have to worry about really going once and then on the back end, it connects to all of these services, let’s call them, or apps.

    And so, from my point of view, that’s a great thing. From your point of view, Justin, right, now you’ve gotta hook into all of these different, new apps and services. How do you do that? Is that via API? Is it a one-off for every one you’ve gotta go into? You know, what’s involved there if I bring you — you know, some app you guys haven’t encountered before?

    McCarthy: Yep, sure. So, I do, there is an important distinction here. There’s a generation and a category of products that you might call them cloud brokers, right? So, cloud access security brokers, that category where you have a workforce that needs to access Salesforce, needs to access another SaaS application. We consider that sort of part of the market to be something that’s necessary but not our specialty.

    Shimel: Not your place.

    McCarthy: Yeah. So, our specialty is, again, it’s that staff where there’s probably an engineer or somehow technical, there’s a technical name in their role somewhere, and they need access to things that aren’t webpages. And so, for that, the procedure is — hey, I’ve got this maybe let’s say even legacy database or I’ve got this type of terminal access that we do that, let’s say we’ve got a lot of machines that are connected via VNC or something. So, and let’s say that’s not on our official supportive protocols list yet. It’s as simple as, we do an intake, we understand the protocol, we add it to the product — that’s it.

    Shimel: Okay. So, you guys do that. I don’t do that myself. I don’t have to kinda write to an API or something and make —

    McCarthy: Yeah, no, exactly. Any system that feels like any sort of client server access paradigm, we can model it in our, essentially in our platform, and then begin granting access to it.

    Shimel: Okay. Almost out of time, Justin. One more area I wanted to hit on this one, though, and that is — talk to me about what to set up here, right? Whether I’m doing it on the cloud, prem, a little of both — how big a job is it to get this thing up and running?

    McCarthy: Yeah. So, we also, of course, have the advantage of — like I said, we’re five years old, but that means we’re only five years old. [Laughter] So, we knew it had to be easy, right? Yeah.

    So, yeah, the act of deploying our proxies is essentially roughly turning it on. Because what then the proxies do is, they take over, for example, topics like discovery. So, they discover what host names they can access and they begin exposing it back to it in the administrative console. So, that’s the one aspect that, you know, deploying it is pretty much turning on the software.

    Additionally, because so many of our customers rely heavily on automation for their DevOps, another way to think of it is, if you already have, if you already have a great Terraform setup that you’re happy with, you have a great cloud formation setup that you’re happy with, we are gonna integrate natively with that setup as well. So, it’s going to be, you’re essentially the overlay, your proxy overlay on your existing infrastructure is gonna go in and it’s gonna feel exactly like anything else that you’re familiar with deploying via Terraform or inside your Kubernetes cluster, for example.

    Shimel: Perfect, man. All good stuff. Justin, I promised you we were gonna do 15 minutes, but I blew it — but not too bad. We’re not too bad. Well, we’re gonna have you back on. It’s gonna be a little bit of a continuing series, right? So, look forward to our next conversation.

    You know what I realized? We didn’t even mention the website, though. So, for people who want more information, it’s strongDM, S-T-R-O-N-G-D-M-dot com, right?

    McCarthy: Yep.

    Shimel: And then can get, if they wanna go check stuff out there. And we’ll have you back on real soon and continue this, man. Sounds great.

    McCarthy: Great. Alright, thanks a lot, Alan.

    Shimel: Alright. Justin McCarthy, CTO and co-founder of strongDM here on DevOps Chat. Hey, this is Alan Shimel, and you’ve just listened to another DevOps Chat.

  • An Open Letter From MediaOps

    An Open Letter From MediaOps

    On behalf of all of us at MediaOps, we are so deeply troubled by what is going on in the world around us. As we continue to battle a deadly pandemic and the effects of racial injustice, the idea of devolving into factions and hurting one another cuts to the core of our being. This is a time in which humanity needs to come together. The following quote from former President George W. Bush sums up my feelings about the current situation—a situation that has been evident for far too long.

    “America’s greatest challenge has long been to unite people of very different backgrounds into a single nation of justice and opportunity. The doctrine and habits of racial superiority, which once nearly split our country, still threaten our Union. The answers to American problems are found by living up to American ideals — to the fundamental truth that all human beings are created equal and endowed by God with certain rights. We have often underestimated how radical that quest really is, and how our cherished principles challenge systems of intended or assumed injustice. The heroes of America — from Frederick Douglass, to Harriet Tubman, to Abraham Lincoln, to Martin Luther King, Jr. — are heroes of unity. Their calling has never been for the fainthearted. They often revealed the nation’s disturbing bigotry and exploitation — stains on our character sometimes difficult for the American majority to examine. We can only see the reality of America’s need by seeing it through the eyes of the threatened, oppressed, and disenfranchised.” ~ President George W Bush

    When we initially came up with the idea of today’s TechStrong Con virtual conference, we wanted to show that the tech industry is indeed strong. What made it strong was our desire to collaborate, communicate and share our collective knowledge—that tech would be the light that leads the path forward to surviving and overcoming the terrible virus in our midst. The event was also designed as a charitable event, to raise relief money for global COVID-19 charities—our way of helping by alleviating suffering and supporting frontline workers.

    Now, we find ourselves with yet another challenge. In addition to the devastating impact of the novel coronavirus, we are once again sadly reminded that injustice and prejudice are very much alive and well in our country. We, like most of you, are horrified by what we are seeing on our TV screens. Even here in the tech industry, we need to do better—not just with racial issues, but with all diversity issues. I firmly believe that we can and will do better. I believe that the tech industry can be a beacon, a light illuminating a path to a better, fairer and more peaceful world for all of Earth’s children.

    I pray for peace and for a time when we can venture out again—together—and focus on improving the human condition for each and every individual across the globe.

    Until then, we have decided to split our charitable donations from the proceeds of the TechStrong Conference. $10,000 will be going to the Southern Poverty Law Center, whose mission is to fight hate and seek justice for the most vulnerable members of our society through litigation, education and other forms of advocacy, working toward a day when the ideals of equal justice and equal opportunity are a reality. Another $10,000 will be donated to the World Health Organization to fight COVID-19.

    With today’s TechStrong Con virtual conference and everything beyond, we move forward with the hope that we can and will do better as a nation, as a people and as one world.

    With Peace,
    Alan Shimel
    CEO, MediaOps

  • Low-Code and RPA With Appian CTO Michael Beckley

    Low-Code and RPA With Appian CTO Michael Beckley

    On the eve of the first virtual Appian World, we caught up with Appian founder and CTO Michael Beckley. Michael spoke to us about low-code and RPA as well as AI and robotics, all being leveraged to help organizations during the COVID-19 crisis.

    Obviously, given the current situation, developing applications quickly with a minimum of coding while harnessing automation and AI would be a big premium. This is a situation that seems perfect for Appian.

    In fact, the whole low-code and RPA model seems tailor-made for a COVID-like situation. Michael shares with us several instances of healthcare and governmental agencies using Appian and RPA to deliver massively scalable applications to measure and gather data around COVID-19.

    Low-code and RPA are not just COVID-19 trends, either. Michael and I discussed why the new normal will reward organizations that use RPA and low-code, as well as harnessing AI and robotics to build apps that can scale massively quickly with minimal coding.

    If Michael is correct, Appian is in an enviable position to deliver a robust, proven platform that will allow organizations to harness the power of low-code and RPA.

    My discussion with Michael is below. While Appian World virtual kicks off today, Michael actually delivers the keynote for the second day of Appian World on Wednesday. If you get a moment, don’t miss Michael’s talk. He has some great insight into how low-code and RPA can be a benefit during the COVID-19 crisis.

    While you’re at it, I highly recommend attending as much of Appian World that you can. I had the pleasure of attending one in Miami two years ago and was very much looking forward to this year’s event in Ft. Lauderdale, before it was converted to a virtual event. Appian’s hackathon is usually a great event to check out at Appian World as well.

  • DevOps Chats: Shadow Code Security with PerimeterX

    DevOps Chats: Shadow Code Security with PerimeterX

    When the cloud first caught on, there was a problem with Shadow IT—developers spinning up instances in AWS without the IT team knowing they existed. Now with the ease of CI/DC automated deployments, the problem of Shadow Code—code being added to apps that did not go through the entire team process—has arisen.

    In this DevOps Chats we speak with Elad Koren, VP of product at PerimeterX, about the Shadow Code issue and how his company can help.

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

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel, and you’re listening to DevOps Chats. Today’s DevOps Chats features Elad Koren, who is VP of product at PerimeterX, and Elad, welcome to DevOps Chats.

    Elad Koren: Thanks, Alan. It’s an honor being here. Happy to join you.

    Shimel: I appreciate you being here, and it’s our honor to have you. So, Elad, we’ve never—I don’t believe so—we’ve never interviewed or covered PerimeterX before on Security Boulevard or DevOps. And why don’t we start with, why don’t you give our audience a little background—what’s PerimeterX about?

    Koren: Cool. I believe you’re right. PerimeterX has been around for a bit more than five years, and its main goal is to secure businesses, digital businesses across the web. It can be e-commerce, SaaS, and other online businesses, essentially providing solutions to the online digital challenges they have.

    We started with our Bot Defender solution about four years ago, and this targets the bot problem around the web. I’m sure you’re well aware of it, being the security professional you are. About a year ago, we’ve also launched our Code Defender product, which looks at the client-side code and highlights vulnerabilities and issues around that. And we will, of course, develop some more in the future as part of our growth plans to continue in securing digital businesses around the world.

    Shimel: Excellent. So, we’re gonna dive into that in just a second, but Elad, I also always like to ask people about their own personal journey. How did you come to be VP of Products at PerimeterX?

    Koren: Wow. [Laughter] It was a long journey. I’m actually, I’ve actually been in security for more than 15 years. I started with the Israeli Intelligence and the IDF. Then moved to my startup where I took all the security and kind of compliance and fraud areas. From there, I moved on to RSA Security, so you’re probably familiar with RSA Security, now part of Dell. And after a short period in Payoneer as their Head of Compliance and Security, I found myself in PerimeterX, leading the product group and now the VP of Product. I’m very proud of what we do with really, a sense of accomplishment with what we’ve been doing so far.

    Shimel: Excellent. Well, RSA Security was spun out of Dell now, right? Didn’t they do a PE deal a couple months ago, I thought?

    Koren: Yeah, yeah, they had a discussion around that. It was actually interesting because RSA was one of the biggest assets EMC had before Dell acquired them. And once Dell stepped in, I think RSA wasn’t that interesting for them, so it was only a matter of time.

    Shimel: Yeah, no, Dell seems to have a love/hate relationship with the security companies they acquire, but that’s for another podcast. Let’s stick to PerimeterX. [Laughter]

    So, client-side code inspections and security—talk to us a little bit about what you’re doing there and then I wanna jump into this concept of shadow code that we spoke about off-mic.

    Koren: Yeah. So, first of all, very important to understand, you know, the first question that comes to mind is, why are we talking about it on devopsy.kinsta.cloud. So, one of PerimeterX’s top targets is to assist DevOps teams to do their job better. And the fact of the matter is that, after we’ve had our bot mitigation solution for quite a while and DevOps was one of our personas, we went out and asked our customers, what’s their next major problem.

    And one of the things that came up for many, many customers was the fact that they have a challenge around their client side, okay? Developers are adding libraries—well, you know, it’s a common practice. However, some of these libraries, JavaScript or others, they’re not that secure, and they’re not that trustworthy. What we did at that point is kind of think of that problem and what it reminded of. And it kind of reminded us of the problem of the shadow IT that we’ve seen about 10 years ago or so, where employees would just come with their devices or do whatever they want with their bring your own device kind of concept, and companies started fighting that. But at the end of the day, they understood that they have no weight.

    It’s kind of similar with code. Developers will find the best weight to add code, even if it’s a library that they can just take and adjust slightly, and even if it’s a GitHub repository that no one maintains, and these introduce significant risk.

    Shimel: Yeah. Absolutely. You know, it’s interesting, I think no one in DevOps questions anymore when we talk about adding security to the mix. I mean, thank God. You know, a little bit of my own personal journey, right? The reason I got into DevOps is because I thought it was the greatest thing for security. I thought this, the way it came down that this whole DevSecOps movement and shifting left and making developers more aware of security—I envisioned that when I first found out about DevOps. And I was hoping it would give us another chance to do it right, to correct some of the mistakes that were kind of inherent in our whole model.

    And I’m not saying it’s a panacea or it’s perfect now, but certainly, we can acknowledge that developers do care about—no one wants to develop insecure or crappy code. People have pride in what code they develop. Now, when they didn’t know—the more they know about security and the more tools we can give them that allow them to kind of do better, develop more secure code, the better off we are, I think.

    But this issue of, as you’re calling it, shadow code, right, kinda growing ________ with shadow IT when the cloud first came.

    Koren: Yeah.

    Shimel: It’s a problem. And the thing about it is, again, developers don’t raise their hand and say, “I wanna sneak around. I wanna sneak a little code in the back door.”

    Koren: Exactly.

    Shimel: Right? They do it because they have time constraints, they wanna get it done, they want it to work faster, right?

    Koren: They’re exactly the reasons that we’ve understood when we looked into it.

    Shimel: Yeah.

    Koren: And it makes sense. If you think about it, developers should be able to add whatever it is that they think can help them develop faster. I mean, it’s the business goal.

    Shimel: Mm-hmm.

    Koren: The main question that we asked is—well, how can you make it more streamlined, okay? How can you—and now, going one step backwards or sideways, there’s a disconnect, okay? The developers, as you said, they wanna make it a secure code, but the business owner or the person who manages the security posture of the application doesn’t necessarily know that somebody introduced a new vulnerability, because the developer thinks that this repository is safe. I mean, it should be, it’s in GitHub. [Laughter]

    Shimel: Oh, no—agreed.

    Koren: So, the thing is—and this is where we asked around, our customers, what are they doing to mitigate this type of risk and what are they finding out. And what we found out is, interestingly enough, you have a lot of performance monitoring tools, but you have zero security monitoring tools on client side in real time. You have static code analysis, you have a lot of other solutions trying to find the vulnerability before it goes out to production. But once it’s out there, nobody monitors.

    And you have to keep in mind—I know you are keeping in mind, but our listeners—the fact that, well, when in run time, you can inject dynamic code, that changes. And if somebody else gets control over it, this is a problem.

    Shimel: Yeah, yeah. Well, and there’s a couple, I think, other complicating factors, Elad, that I’d like you to address. And that is, you know, today, where does that client side code live? Is it in the container somewhere with the whole Kubernetes microservices mesh thing goin’ on?

    Koren: Mm-hmm.

    Shimel: Is it in the traditional hypervisor kind of environment, or maybe something like that or is it on bare metal and serverless or—you know, it’s a great time to be a developer, but it’s a very hard time to be a security person who’s trying to keep guardrails there for these people to do it as safely as possible, as securely as possible. How do you do that?

    Koren: This is correct. You’re spot on. You’d expect that when a new code is introduced, the company or the developers would adopt it and manage it or maintain on their servers or on their microservers or their mesh. However, because they want to keep it updated, because they want to keep it as capable as possible, they sometimes take the dynamic library from their repository and, whenever there’s a CI/CD process going on, it pulls the library from there.

    And that is where the shadow code becomes a problem. Because, unless you have the right processes around, how to make sure that this library is safe? How to make sure that this is, you’re not introducing anything malicious—and we have seen it happening in the past—this is where you have to address the problem. And you know, I can share some of the things that we’ve seen when we had the validation of the product before we launched it. We had a design partner, and they asked for something like this because their developers asked for the security team to allow them visibility into what’s happening on the client side. And we’ve actually—and it’s a big customer. I don’t want to name names, naturally, here, but—and you will share my surprise—when we found out, when we run on their client side that a very, very big vendor of there is using a jQuery from a non-trustworthy source.

    Now, you’d expect something like this would never happen for a well-established company, but it does. And it’s surprising, but it does. And they weren’t the only ones.

    Shimel: Hmm. Interesting. So, let’s now talk—so, I think we’ve defined the issue and the problem, right? How is PerimeterX helping this?

    Koren: So, our approach when looking at this issue or this problem, naturally, we are a Dev first company. So, we came and asked the developers that we were working with—the DevOps, DevSecOps, and some of the risk analysts, some of the personas—what would be most beneficial. And what they said, and this is how, you know, I’m the VP of Products. I’m a Product Manager at heart. And customer input is the number one thing that I’m looking into when I’m building the products.

    They said very clearly, if they can see, before moving from staging to dev to prod, what the code itself, when it’s pulled dynamically, is doing and have the visibility of what’s happening there in real-time on users—this is something that they don’t have today. Because that will introduce that level of visibility whenever something bad happens.

    I don’t know if you’ve seen some of the Magecart attacks that have happened from third-party libraries. Again, don’t wanna name names, but if somebody looks online, they can find out. When we come in and we analyze in real-time on the client side, on every user going into the website, what the scripts are doing there, whether they send information to a bad domain, whether they try to take the information and store it in a cookie and then use it later on—we can quickly highlight the main risks and main problems and vulnerabilities, like I mentioned earlier with jQuery, so that the DevOps or DevSecOps can quickly raise a flag and say to the developer, “Listen, this script you’ve added introduces new vulnerability.” You can’t see that in the static code analysis, but you will see that on run time on the client side. And that is something revolutionary. We don’t have that today in anyone else’s solution out there.

    Shimel: Hmm. Interesting. What—so, I always ask, and you’re the perfect person, VP of Product—now you’ve got a conundrum. You’ve got a really great security product here that’s gonna help developers with secure code. How do you—how do you sell it? How do you bring it into the organization? Do you talk to the security guy and say, “Hey, go talk to your developer team and tell them to use this?” Do you talk to your developers and say, “Tell your security team you wanna do this?” Do you gotta talk to the security team and the developer team? Whose budget does this come out of? Who ultimately is responsible for setting the policies and processes?

    Koren: And this is—

    Shimel: Is the solution hard to sell, maybe, though?

    Koren: You’re correct. So, theoretically, it’s hard to sell. However, the main key here or the key differentiator is the fact that when we went in to look how we wanna sell this solution, before we even built it, we established the fact that it should fit into their processes. If it’s not fitting into their processes, if they have to start defining things like content security policy, if they have to start maintaining this on a day to day basis, it’s not going to work.

    Solutions for DevOps or DevSecOps today are one, two, three. You have to have it in and you have to do it quickly and you have to have minimum manual effort, unless you definitely prove why it’s needed. And so, this is why we’ve added the fact that nobody needs to do the baselining on their own, we are doing that automatically with machine learning capabilities, what every script does, whether it’s ________ or not, and the fact that they can just have a small snippet on their client side and we’ll analyze whatever and flag in our portal or alerting system that they have, it actually fits into their CI/CD process, it fits into their day-to-day process. They can even have it as part of their regular security processes and have it fit into their SIM.

    And this is where it really makes the difference, because you don’t have to do anything manually and you solve a problem and you fit into their processes, and security people are very happy about it. I can tell you that one of the customers that actually already bought this product was very happy with the fact that they have visibility to this area and they don’t have to maintain it on their own, because we are doing that, the product does that out of the box. So, this was a key component in our product.

    Shimel: Huh. Excellent. Excellent, excellent. So—I told you, the time goes very fast. [Laughter]

    Koren: [Laughter]

    Shimel: We’re coming up on time, here. For people who are interested—let’s use our time wisely—how could they find out more information? What path do you suggest for them?

    Koren: So, first of all, they can go out to our website and check out our solutions, both for bot mitigation as well as the Code Defender and other solutions that we have. I think reaching out to our team if you have any questions, if you have any concerns around the client side, I can tell you that even companies that thought everything’s fine were completely oblivious to threats and concerns around the client side that are out there and many people are not aware of. You can also reach out to me directly via LinkedIn or what have you and we can discuss.

    I think in general, for DevOps and DevSecOps to be more aware of the dynamic nature of the code that is added to the client side and what to do. We actually have a blog post listing the things that are best to do if you want to make sure that it’s secure and you’re on top of things. So, it’s a good read as well. And that’s about it. So, we are here. We’re ready to help.

    Shimel: Cool. Last question, just because you have to ask it because it’s out there—with everything going on in the world with the COVID and everything else, how is it affecting you guys and what are you seeing?

    Koren: It’s actually amazing. We’ve seen some trends around the e-commerce landscape that we’ve actually had some blog posts on. And I think, you know, one of the things that kind of symbolizes these times, a few of the e-commerce sites that we are working with said that the traffic they experienced outgrows the Black Friday/Cyber Monday level of traffic.

    I think it symbolizes kind of the boom of online life that we have. I’m sure you’re experiencing it as well. And I think the shift there is not going to go back to the previous levels. It’s definitely going to go down, but we are seeing so many trends, very interesting trends, and we are naturally adjusting what we are doing, but luckily and happily, we’re doing great these times and it’s—we’re very happy with what we have now.

    Shimel: Well, I will tell you, for whatever reason, you know, and it may not all be good, because there is this whole, with the virus pandemic there’s a cyber pandemic of people trying to exploit. I mean, so, for instance, even here MediaOps where DevOps and Security Boulevard, our security site, used to be pretty even in terms of how many visitors—they both get 350 to 400,000 visitors, unique visitors.

    Koren: Mm-hmm.

    Shimel: All of a sudden, you know, Security Boulevard now this month is gonna be at 600,000.

    Koren: Wow.

    Shimel: Last month was 530,000. So, in the last two months since this COVID thing, you know, we’ve seen traffic on the Boulevard site—DevOps has stayed relatively steady. It hasn’t gone up, necessarily, it hasn’t gone down.

    Koren: You know, one thing we’ve noticed, and I think it can also explain, I think it’s wider than that—attacks and in general fraud and security challenges became much more complicated, because the adversaries are out there and they are targeting a whole lot of other new sites that previously didn’t experience. We are seeing much higher levels of complexity in the attacks that we’ve previously seen on giants, now on even medium small—small- to medium-sized sites.

    Shimel: Agreed. Crazy. Just crazy, right?

    Koren: Yeah, indeed.

    Shimel: You know, because that’s what you need when you have a virus pandemic, we need to have more cybercrime and that stuff to worry about.

    Koren: Yeah. [Laughter]

    Shimel: So, Elad, I want to thank you for joining us today on DevOps Chats. It’s been a pleasure.

    Koren: Thanks, Alan.

    Shimel: Be back on soon. Elad Koren from PerimeterX here on DevOps Chats, this is Alan Shimel and you’ve just listened to another DevOps Chats.

  • TechStrong Con: 12 Hours Strong, June 4

    TechStrong Con: 12 Hours Strong, June 4

    In my previous article, I noted that as part of our COVID-19 response MediaOps has spun up TechStrong TV, a daily video stream. Additionally, we are hosting our biggest virtual event to date, TechStrong Con, for 12 hours strong on June 4. We want to make TechStrong Con our biggest, best virtual event to date. We want to show that while we may be working from home battling this terrible virus and dealing with economic upheaval, the tech industry is unbowed. We collaborate, we communicate. We develop, we deploy. We are strong, #techstrong.

    I know what you are thinking: Hmm, another virtual event, joy. Just what we need. Yeah, I am with you—it does seem like everyone and their mother are putting on virtual events, or at least calling what they are doing virtual events. But really, this one is different. Here is why:

    1. The speaker lineup is extraordinary. John Willis has handpicked the speakers in the main room auditorium. The lineup is not final yet but already includes an amazing mix:Seriously, this is a blockbuster lineup of speakers. In addition, there will be multiple auditoriums as well as the main stage, all with great speakers. One of the advantages of a virtual event is you don’t have to miss one speaker if two great talks are going on at the same time. The sessions will stream live at their given time and be available on-demand.
    2. There will be chat rooms built into the event itself. Many of the speakers will be available live in the chat rooms after their sessions to answer questions or chat with attendees.
    3. The event will be 12 hours chock full of all kinds of tech learning, networking opportunities and a chance to escape the bad news.
    4. A job board will be available for companies looking to hire and those looking for work.
    5. A portion of sponsor proceeds (it’s free to attend) will be donated to COVID-19-related charities.

    The whole event will take place in our state-of-the-art virtual environment, which we have been steadily improving for the past 24 months. This really is one event you don’t want to miss. Also, if you are interested in sponsoring or speaking, write to me at editor@devops.com.

    Stay healthy. Stay strong.

  • TechStrong TV: Celebrating the Strength of the Tech Community

    TechStrong TV: Celebrating the Strength of the Tech Community

    I wanted to tell you about two important initiatives we have been working on around here, TechStrong TV and TechStrong Con. They are a big part of our COVID-19 response. The past four weeks (has it been just four weeks?) have been a blur. The MediaOps team has shifted into overdrive to keep all of our sites up and running and our webinars, virtual conferences and other activities on track, all while working from home. But that wasn’t enough—we wanted to do more.

    TechStrong TV and TechStrong Con are the things we have chosen to do. Communication and collaboration are so core to the tech industry, and we wanted to help show it is #TechStrong. So let me explain what TechStrong TV and TechStrong Con are.

    This first of two articles focuses on TechStrong TV. TechStrong Con will be the focus of the second article.

    TechStrong TV

    TechStrong TV is a streamed broadcast for two to three hours daily Monday to Friday. Each episode features a fresh set of news, interviews and other content.

    The broadcast streams here on devopsy.kinsta.cloud, as well as on Container Journal and Security Boulevard. It also streams on our Facebook pages via Facebook Live and our devopsy.kinsta.cloud pages on LinkedIn via LinkedIn Live, as well as on Digital Anarchist and TechStrong TV. Select interviews from the daily shows are available standalone on the Digital Anarchist site.

    Perhaps the best way to view TechStrong TV, however, is actually on your TV. Through our devopsy.kinsta.cloud app on AppleTV, Roku and Amazon Fire you can view episodes on-demand on your TV. You can also view on your phone or on tablets on the devopsy.kinsta.cloud mobile app.

    TechStrong TV Content

    You know for the last year and a half and even before that we have been traveling around the world streaming video interviews from conferences near and far. We have a full media studio in our offices. We wanted to keep that stream of interviews going.

    With so much bad news on the mainstream news shows, our thought was, Let’s concentrate on the tech industry. What are people doing? What are vendors doing? What are you experiencing while you’re working from home? We explore all of this and more on TechStrong TV. We also mix in from the Digital Anarchist archives and our YouTube DevOpsTV channel some of the best interviews we have done on-site over the years.

    We shoot the show with one video person and me in our office. Mitchell Ashley, principal analyst at Accelerated Strategies Group, and MediaOps Managing Editor Charlene O’Hanlon are my co-hosts, recording segments from Colorado and Virginia, respectively. Additionally, we feature weekly segments by John Willis and Jayne Groll and twice-weekly segments on the channel by Mike Vizard.

    We hope to add more regular segments by some of the Accelerated Strategy Group team and other tech leaders.

    More Than Just Tech Segments

    We recently added WFH Fitness with Jeremy Jones to the TechStrong TV lineup. Jeremy is on our sales team but is also a certified personal trainer, having worked as a personal and group fitness trainer for years before joining MediaOps. He brings his knowledge of fitness to the TechStrong TV airwaves two or three times a week, recording a 20-minute workout circuit for those at home without access to gym equipment. The exercises are good for any level of fitness, from beginner to advanced, and using equipment you have around the house (think water jugs and canned goods).  These workouts are available as standalone, on-demand segments on TechStrong TV and the OTT channels (Roku, AppleTV and Amazon).

    In addition, we created a community Slack channel, which you can grab an invite to when you visit the TechStrong TV website. This way you can interact with the guests and our team in real-time.

    The New Normal

    Personally, this is the longest I have been home with no business trips in probably 15 or 20 years. Being a road warrior was a big part of my life in technology. For those like me, this new normal has taken some getting used to. But TechStrong TV gives me the communication and connection to the industry I crave. I hope it does for you as well.

    If you or someone you know would like to be featured on a TechStrong TV segment, reach out to us at techstrong@devops.com. We are also looking for sponsors if any tech vendors are reading this (I would bet there are). In just a few weeks, we are already entertaining 5,000 to 6,000 people each day.

    We are going to keep TechStrong TV going even when we return to normal (or whatever the new normal is). It is improving every day and I hope it will continue to do so.  I invite you to check it out and give your feedback so we can continue to make it better.

    Again, I will detail TechStrong Con in my next article. But until then, during these surreal times, the whole MediaOps team and I hope you stay safe, stay well and stay strong. #TechStrong