devopsy.kinsta.cloud

Category: DevOps Chats

  • DevOps Chat: Enterprise Multi-Cloud Backbone With Aviatrix

    DevOps Chat: Enterprise Multi-Cloud Backbone With Aviatrix

    Our podcast guest believes the world changed “on a Tuesday” six months ago when the enterprise move to the cloud became imperative, not just an aspirational goal. That eureka moment was enough to pull Steve Mullaney off the sidelines and back into the game as CEO of Aviatrix after successful executive gigs at Palo Alto Networks and Nicira.

    “Go build” might be a wonderful approach for cloud-native apps, but enterprises want the framework laid out ahead of their move to the cloud. Think enterprise cloud IT reference architecture, much like Cisco provided for enterprise IP networks, DEC mainstreamed for client-server and IBM established for mainframe computing. You have to bring the cloud to them. That enterprise cloud reference architecture is what Aviatrix targets, in the same buy-with-a-credit-card model that fueled customers’ unfettered move to AWS.

    On our DevOps Chat podcast episode, Steve Mullaney, CEO of Aviatrix, talks about what enterprises want in a true enterprise multi-cloud backbone to support their needs.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Steve Mullaney, CEO of Aviatrix. Our topic today is enterprise multi-cloud backbone—meaty, good stuff.

    Steve, welcome to DevOps Chat.

    Steve Mullaney: Thanks for having me, Mitch.

    Ashley: Great, good to have you here. I’d like to start by having you introduce yourself. I know a lot of us know you from your background, you’re a fairly well known guy, but tell us about yourself.

    Mullaney: So, yeah, my name is Steve Mullaney, I’ve been in networking and security infrastructure for, really, the past 35 years. I actually started my career in the mid-80s as we were kind of evolving from, transitioning from the mainframe computing model into client server. I was actually an engineer on 10Base-T from the company called SynOptics. So, those of you who’ve been around long enough to remember when Ethernet was starting and—

    Ashley: I do recall.

    Mullaney: 10Base-T started, yeah. So, I spent most of my career in networking and security, I was a very early guy, actually, also at Palo Alto Networks, I was the first VP of Marketing there, employee number 25. And then was CEO of a company called Nicira, which was really kinda the beginning of a lot of this SDN craze and network virtualization. We were acquired by VMWare, and then I stayed at VMWare for a couple years and grew that business, which is now almost a $2 billion business and a ________ business.

    And then, for the last five years, I just, I kind of said no more operational roles and was on boards and I was content to just do that the rest of my life and very happy living the dream. And I saw the world change about six months ago, where enterprises have been talking about the movement to a cloud computing model—honestly, talking about it for the last 15 years, but I noticed really about 6 months ago is when mainstream enterprise really said, “Okay, we are doing this.” And I just looked at that opportunity and said, “My God.”

    And I was on the board of Aviatrix at the time, so I could see this happening up front and just said, “This is just gonna be too much fun not to be involved.”

    Ashley: So, what was it? What was it six months ago or so? When was the nexus point when you saw a change that pulled you out of retirement?

    Mullaney: Yeah. What was interesting was, I love to say, six months ago on a Tuesday. And it felt almost like that much—like, literally on a Tuesday. And that’s how enterprises move, right? They talk about it, they talk about it, they talk about it, they talk about it. It’s like going on a diet. You talk about it and, “I’m gonna go on a diet.” “Well, how about today?” You’ll say, “Well, you know—not a good day.” “Well, how about tomorrow?” “Well, you gotta start on a Monday,” right? And then, “How about next Monday?” “Well, that doesn’t really work, because I’m going on vacation.”

    I mean, there’s all these excuses, and enterprises, about five years ago, really said, “Alright, we are gonna move to the cloud.” And honestly, that’s when every enterprise vendor went, “[Gasps] We’re dead!” Right? “We’re dead. Everything’s gonna go into Amazon and we’re dead.”

    Ashley: Mm-hmm.

    Mullaney: And what happened was nothing, because the enterprises were just talking. They didn’t really mean it, right? So, everyone went along their merry way with quarter after quarter of record highs. Until about six months ago, I’m on the board of Aviatrix, a bunch of other infrastructure companies and I notice the logos are changing. This isn’t Netflix any more, this isn’t small to medium businesses, these aren’t early adopters. These are Midwest manufacturing, conservative companies. What the heck is goin’ on? They shouldn’t be doing this!

    And people think just because AWS is at a $30 billion run rate that we must have crossed the chasm by now. We haven’t. And I’ve noticed, across all of my infrastructure companies that I was on the board of, they’re seeing all the same thing. No one’s done anything different, it’s just, the market just changed. And the way enterprises go, they are a herd mentality. When the majority, you know, the early and late majority of customers all decide to do something, they all decide on the same Tuesday morning, and I saw that happen.

    We saw it with client server. I was at SynOptics at the time. Mainframe computing was the way you did enterprise computing, and client server—PC client server was treated as a toy, just fun and games. So, print sharing, right? PCs—that’s not real computing, right?

    Ashley: Mm-hmm, mm-hmm.

    Mullaney: And then what happened? All of a sudden, in the early ‘90s, on a Tuesday morning, everybody decides the Internet Protocol is the only protocol that matters. All the other protocols went away overnight, and PC client server is the way I’m gonna build up my architecture—and it happened overnight. I saw the same thing happen with cloud.

    Ashley: Mm-hmm. So, it’s really kinda going mainstream, you’re seeing a real—

    Mullaney: It’s gone mainstream. And I’ve been at the company now for three months as the CEO of Aviatrix and every day, I just see more and more evidence of that, that companies are burning the boat—meaning, the corporate data center, the corporate backbone that is dead. It is now an expense. I view it as an expense, and I view anything I do in the public cloud, leveraging the public cloud, as an investment.

    Ashley: Mm-hmm.

    Mullaney: And that means all my people are focused on that as well as all my expenses. And it shifts overnight, and it’s a herd. Every single enterprise around the world is now making that same decision on the same Tuesday morning.

    Ashley: Mm-hmm. I love your Tuesday morning analogy.

    Mullaney: Isn’t it funny? It’s really true, though—it’s really true!

    Ashley: [Laughter] It just seems like it suddenly happened.

    Mullaney: Yeah.

    Ashley: So, you’re on the board of multiple companies. What was it about Aviatrix that you said, “This is the one I’m gonna ride. This is the one I’m jumping on board, I’m gonna be CEO, take this baby where it’s gonna go”?

    Mullaney: Yeah, I think it goes—because it goes in terms of what we say our mission, our mission is to build the enterprise multi-cloud backbone.

    So, when you look at AWS and Azure and GCP and even AWS’ mantra to enterprise is, “go build.” Well, that’s great when you’re an early adopter and they hand you the power tools, and you—

    Ashley: Mm-hmm, the greenfield.

    Mullaney: Yeah and you are that innovative, you wanna go build. That does not go very well when you’re a Midwest manufacturing, conservative company. I’m gonna cut my arm off with power tools. I don’t want power tools. I want a house, I want furniture, I wanna walk in with it done. I don’t wanna build anything.

    Ashley: I want a landing strip, I don’t wanna build the runway.

    Mullaney: Absolutely. I do not wanna build. And so, I think this, honestly, has caught AWS off guard, too, right? Because they’re thinking—all of our customers love that, a “go build” mantra. Not the mainstream, right? Not when it flips. Not when you’ve crossed the chasm and now you’re in the tornado and everybody just, they’ve gone and said, “This is it.”

    And so, I looked at that, and I said, “My God, all of these enterprises are begging—begging—someone to define the architecture for them.” This is just like in the client server where they needed Cisco to come out and define the networking and security architecture for them. Give me the canonical architecture that everyone’s gonna do, and then I will go implement that.

    Ashley: And it’s proven, we’re not inventing.

    Mullaney: And that’s what people want, and they want a validated design. They wanna be able to go, “This is what everyone’s doing, we’ve all agreed, this is what you do. And oh, by the way, I can’t get that from Amazon, because Amazon’s trying to lock me into Amazon. I can’t do it—I can’t get it from Azure or Google. I can’t get it from the old world, I can’t get it from Cisco, because they don’t even understand this,” right?

    Being able to—it’s just like, you wouldn’t go to IBM or Deck for the client server architecture. This is a whole different computing model. You can’t—by definition, the leaders of the old are never the leaders of the new. So, who do I go to?

    Ashley: Yeah, and to the point of multi-cloud, you’re probably not gonna be in just one, yes? It might be appealing to be in Azure for some Microsoft apps, but you also have compelling reasons to be elsewhere.

    Mullaney: I have not met an enterprise that says they’re only gonna be in one cloud. They’re in at least three. Because then you’ve got, if you’re in China, you’re in Alibaba. Then you’ve got, you know, data sovereignty and GDPR and all these kinda other issues that I may have to have multiple providers in Europe, country by country, right? And not even AWS.

    And so—sure, absolutely, it is going to be, and it should be. Because not that you’re gonna move workloads between one to the other. Like, that’s not gonna happen. But what is gonna happen is, maybe the marketing team likes GCP for AI reasons or, you know, I started with Office 365 in Azure and so I’m moving off on that. Or I’m a big enterprise, manufacturing enterprise and Microsoft really understands me. Or I’m a retail and I will not have anything in AWS, right?

    Ashley: Yeah.

    Mullaney: Or I see, even, I’m a customer, I’m a company—a software company. I’m selling to other enterprises. I cannot have my infrastructure if I’m selling to retail. I cannot even have my own internal infrastructure on AWS because they don’t want that to happen.

    So, absolutely, it has to be across all this. And then the other thing is the “go build” mantra—so, even if you could say, “I can figure out how to go build on AWS,” the constructs in Azure and GCP are different.

    Ashley: Right, you’d have to go build everywhere.

    Mullaney: So, now I need to learn those constructs, and now I have to go build there, but with different tools that work differently—like, one’s in metric and one’s in an American system. It’s like—oh, my God, you know? And the tools don’t work. Like—okay, this is ridiculous.

    Ashley: So, you painted a picture of multiple compelling reasons somebody needs to lay the groundwork for me. I’ve gotta be multi-cloud, so I need that reference architecture that’s gonna work across multiple providers. I don’t wanna stick build any more, I wanna be able to walk in and plug my application into a framework, a reference architecture that I can use—that’s what Aviatrix is about?

    Mullaney: Yes. And then layering on top, leveraging the constructs, right? Leveraging the wonderful underlay, right? Of all—think of all the fiber, and the pops, and the data centers, and the regions, and all the wonderful stuff underneath that AWS Azure and Google provide, and growing.

    Ashley: All that infrastructure you don’t have to do.

    Mullaney: That is unbelievable, right? And guess what? I’m an over the top networking and security software player. So, when you think of guys like WhatsApp, you know, AT&T used to always get really mad because WhatsApp gets bought by Facebook for like 30 billion or whatever it was, and AT&T with all their fiber and all their different pops and all their right of ways and everything else like that—what’s their market cap? I don’t know. Probably not even much more than that. And you go, “Why is that? Like, I do all this stuff and I get no credit.”

    Ashley: Spend a lot more money getting there.

    Mullaney: And then WhatsApp with, you know, six engineers gets bought for $30 billion, where’s that? Well, yeah, because the over the top guys, that’s where all the value is. They’re leveraging it.

    So, in a sense, we are an over the top software player, but what we’re over the top of is not the internet on top of AT&T, it’s the new internet. It’s the hyperscalers. It’s AWS, Azure, Google, et cetera, all with massive bandwidth and the best latencies you can get in peering points to each other such that when we overlay these decoupled security services on top, the combination is an amazing architecture and network.

    Ashley: So, talk about those services. Talk about security operations, extensions, transit—all of those things that you need to take care of, orchestration—how does that work with ABHS?

    Mullaney: Yep. Yeah, so in this what we call the enterprise multi-cloud backbone, there are, you know, today probably seven or eight different services that a customer can start with. And the beautiful thing about this, again, you can use Aviatrix. We have over 300 customers right now and growing rapidly all over the world—customers all over the world. We don’t even know that, because this is low friction land and expand. A real true cloud model where they can actually start. It might be $500 a month. It might be $50 a month. It also could be $3,000 a month. They just start using it, and they might stop with one use case. “Let me try it out.” They get their credit card, it integrates in through AWS Marketplace or the other marketplaces, and all of a sudden, they just start charging. And guess what—next month, they add. Next month, they add. Next month, they add. And then they say, “Oh, I now need additional things,” right?

    So, they may start with a service we call user VPN. So, basically, we take OpenVPN and we add a lot of additional functionality to it, integrating it with SAML and other authentication means, add in some more security controls, and say, “Hey, I’ve got users, and I want them to VPN into the cloud, because I have resources in the cloud. I want them to be able to securely connect them to the cloud.”

    That might be the first use case you start with, and maybe you’re paying $1,000 a month, but from there, it’ll start growing where then you say, “Well, now I need transit networking,” right? Or, “I need egress filtering. So, guess what, I start going into the cloud.” Guess what, most of your VPCs and your resources in the cloud have to access things on the internet for build packages or et cetera, right? Because this is a very distributed, hybrid world. So, it’s not just all inside the cloud. Well, guess what? I wanna do filtering on that outbound, and I wanna do what’s called FQDN, fully qualified domain name, which, I don’t wanna do filtering based on an IP address or let them go anywhere they want. I wanna say, “You can go anywhere, yahoo.com or wherever you need to go for that build package.”

    Ashley: Mm-hmm.

    Mullaney: And that’s it. So you wanna be able to whitelist it, and you wanna be able to define it per user and per VPN. So, you wanna be able to have security policies of who can go where. So, that’s another use.

    Other use case is encryption. You know, right now, people say, “Well, you run”—you know, six months ago, when the cloud was kind of fun and games, “Hey, I’m putting workloads up there, it doesn’t really matter, it’s not my enterprise.” You know, maybe you didn’t worry about encryption. But now, you’re a retail or you’re a bank, you know, and all of a sudden, you care. So, you’re gonna wanna—

    Ashley: Yeah, if you’re gonna put in an enterprise application, you’re gonna miss encryption, security, it’s high [Cross talk].

    Mullaney: Yep, yep. You’re gonna wanna encrypt in flight, right? So, not only do we allow encryption, but we also allow high performance encryption, right, to 10 Gig, 20 Gig, 30 Gig and more, where—you know, and that’s important as people are putting PII data and other things. And also, from a security perspective, people know that—look, I’m just gonna encrypt everything. The data as well as in transit.

    And then, you know, as you talked, being able to do this across multiple clouds, right? So, I maybe can connect, I wanna be able to connect up multiple regions within one of the clouds, but then I also wanna be able to go to the other clouds as well and create one kinda common framework upon what we’re doing.

    And then I’d say another service is what we call firewall network service, and that’s another one, I can talk more specifically about that. But everybody that’s coming to the cloud—again, this isn’t fun and games any more, this is serious business. The first thing they say is what? Security and policy, I need to bring my next generation firewall policies into the cloud with me. And I need—so, if I’m a Palo Alto Networks customer, the first thing I wanna do is, I wanna take my VM series into the cloud. And when I try to do that, the construct of how AWS says you can connect your VM series firewall into AWS forces compromises in performance, scalability and visibility that are just untenable. And, with Aviatrix, we eliminate those trade-offs.

    Ashley: It’s certainly a fundamental component of where you’re gonna start to build out your infrastructure. If you can bring as much of your own network security into the cloud, all the better—that’s your strategy, yeah.

    Mullaney: Yeah. Well, you know, I think what’s important is, and I think guys like Amazon are realizing this, is when you have to deal with, when you’re dealing with the enterprise—and I mean, the enterprise. The Midwest, conservative, classic mainstream enterprise, right? You have to bring the cloud to them. You can’t make them go to the cloud, right? They’re looking at this and they’re saying, “Okay, I’m all in. I’ve burned the boat, I’m gonna get rid of my data centers, I’m all in.” But then they look and they go, “The grass ain’t as green as I thought it really was.”

    Ashley: Mm-hmm.

    Mullaney: There’s a lot of burned out spots, here. This “go build” mantra? Whoa, whoa, whoa, whoa—wait a minute. I thought I was gonna hit a couple clicks and be done. And oh, by the way, CEOs and CIOs of companies, they’re all bought in and said, “Hey, you know, we used to have hundreds of people managing this infrastructure when it was on prem, but I understand cloud. I only need tens now,” right?

    Ashley: Mm-hmm.

    Mullaney: So, the problem is, [Laughter] they go to the cloud, and again, I’m seeing this everywhere, every enterprise said, “We don’t really have enough people.” Like, we got kinda sold a bill of goods, here. Everyone kinda told us this was like click, click, click—you’re done. It ain’t that easy, right? And then you throw across, “Now, I’m gonna do it across multiple clouds—I don’t know how we’re gonna do this.”

    Ashley: Well, let me ask you, then, we’re coming up on the end of our time here, together—if you had one parting recommendation thought for those enterprises that are in that first six months window and really looking at moving to the cloud or are in that process, they wanna check out Aviatrix, they wanna maybe do a prototype or look at the reference, how they build a reference architecture on the platform—how do they get started? What’s the best way to do that?

    Mullaney: I mean, the first thing I always tell people, the best way to get started is actually just get started. The good thing about this modern world is, we don’t have to do a POC. We don’t have to—you can actually get started over the weekend, and that’s how many of our customers start. They just start playing around with our software, like on AWS Marketplace, it’s a great place to start. They just spin up a controller, they spin up a couple gateways, they—and we have quick start guides to show you how to do it in a very easy way. And people start playing with it and they go, “Oh, that’s pretty interesting.”

    And so, they start with kinda one use case, right, and a very small little bit and they effectively do their own little POC. And they say, “Okay, that’s pretty interesting.” Now, we can also do it for them, but that’s a pretty good way to start.

    And then I’d say the other thing is, what you really are gonna look for—I mean, there’s only one reason why people aren’t using Aviatrix right now is because they’ve never heard of us. As soon as they—as soon as we talk to people, they’re sold. Because they look and they go, “This is exactly”—people say, “That’s exactly what I’m looking for. I need someone to help me build out my multi-cloud, my enterprise—my, my, not someone else’s, my enterprise’s multi-cloud backbone, and all these networking and security services that go along with it. That’s what I need, and you guys are doing it for me? That’s exactly what I need.”

    Ashley: Well, great. I thank you so much for being with us. We’ve reached the end of another DevOps Chat podcast. It seems like there’s never enough time. I’d like to thank you, Steve—Steve Mullaney, CEO of Aviatrix for joining us.

    Mullaney: Great.

    Ashley: And thank you, you, to our listeners for joining us also, of course. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chat. Thanks for joining us.

    — Mitchell Ashley

  • DevOps Chat: Mayhem Testing With ForAllSecure

    DevOps Chat: Mayhem Testing With ForAllSecure

    Secure software depends on people finding vulnerabilities and deploying fixes before they are exploited in the wild. This has lead to a world of security researchers and bug bounties directed at finding new vulnerabilities.

    As dedicated as security researchers are, there is a vast ocean of software in existence, waiting for someone to find and exploit the next security vulnerability for profit or nefarious uses. With autonomous vehicles on the horizon, is there an autonomous solution to finding and fixing software vulnerabilities?

    Enter DARPA Cyber Grand Challenge winner “Mayhem,” created by a team of researchers from Carnegie Mellon University who spun out security startup ForAllSecure. And they have a BHAG (Big Hairy Audacious Goal). “Our vision is to check the world’s software for exploitable bugs so they can be fixed before attackers use them to hack computers.” Mayhem has moved on from capture the flag contests to observing and finding vulnerabilities in DoD software and is working its way to corporate systems.

    In this episode of DevOps Chats we talk with David Brumley, For All Secure co-founder and CEO, and CMU professor about the technology behind Mayhem, how it observes software as it executes and injects changes to effect and observe new and potentially exploitable behaviors. More information about Mayhem is also available at www.forallsecure.com.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by David Brumley, CEO at ForAllSecure. David is also a professor at CMU. He’s currently on leave. The topic that we’re talking about today is called Mayhem behavior testing—it ties back to David’s work at CMU. So, David, welcome to DevOps Chat.

    David Brumley: I’m happy to be here.

    Ashley: Great, we’re happy to have you on the podcast. Would you start by just introducing yourself a little more fully—your background, maybe a little bit about some of the research and how that led you to form ForAllSecure?

    Brumley: Yeah, absolutely. When I got out of undergrad, I was a computer security officer. My job was to chase intrusions on the Stanford network and try to help people fix them. And at the time, I got pretty frustrated with the idea that we were always behind attackers, that I couldn’t find vulnerabilities first or get the fixes deployed.

    I actually went back to grad school, got a Ph.D. and really made that my work since 2003 on how do we go about finding vulnerabilities before attackers and just as importantly, how do we get those fixes fielded? Because it’s not just about finding the vulnerabilities, it’s about how quickly we can get those in place.

    I’ve been working on that, I’m a tenured professor at Carnegie Mellon, and for the last three years, been working on commercializing it.

    Ashley: Excellent. Well, an entrepreneur and a professor, and it’s great to see that your research has led you to kinda bring this out to market. That’s exciting. So, tell us, what is Mayhem? What is Mayhem or behavioral testing?

    Brumley: Yeah, what Mayhem does, we call behavioral testing. So, behavioral testing is about watching an application as it executes and learning from that execution and then trying to come up with a new input that would cause the application to do something different. And you do this again and again and again, like hundreds of times per second, with the idea that if you can learn the behaviors of a program and you can start driving it to new behaviors, you’ll, one, come up with a test suite for the program, that’s important for the DevOps part and how you get things out quickly, and second, things like vulnerabilities and exploits that trigger vulnerabilities are just triggering a particular behavior. So, you can automatically generate inputs that trigger these. At one point, people were saying we were automatically generating exploits with this technology.

    Ashley: Interesting. I’m pretty sure that it’s not the same thing, but it sounds like a more thoughtful and learned approach to what we know as chaos testing from the Chaos Monkeys from Netflix, et cetera. But you’re really picking specific behaviors, building a profile of the application, and then looking for new behaviors that you can test against it?

    Brumley: That’s what we’re doing, and so, there’s really kind of two technologies people may have heard of. One is called fuzzing. So, fuzzing is about running the application again and again and again. And it uses heuristics to pick those inputs, and one of the things we built is a way to monitor that application as it runs and to inform the fuzzer on how to come up with new inputs that would get different behaviors.

    The second that we did is, we really took a page from surprisingly formal verification. So, the formal verification was trying to prove a program was safe. What we tried to do is use those same techniques to prove where a program is unsafe, and our proof creates an input that triggers the unsafe property.

    So, we use these two techniques—fuzzing, symbolic execution and a few others and a portfolio approach to try to come up with behaviors that are exploitable.

    Ashley: Interesting. Do you do this in a production environment, in a test environment, in both? How do you approach this?

    Brumley: For a product, we always do it in testing. We think it’s important to have these techniques out there in testing so that you can find them before attackers. We have done some simulations in production. One of the things we participated in was, DARPA had a big autonomous Cyber Grand Challenge. So, we fielded it there, but we think the market would be in the testing environment.

    Ashley: Mm-hmm. It would definitely make sense—makes more sense there. Say a little bit more about fuzzing and how that exactly works. Is it the software that’s doing the variations, or are you introducing variations to that from what you learn?

    Brumley: We’re introducing the variations, so the idea is, an exploit for a program is just an input.

    Ashley: Mm-hmm.

    Brumley: And, you know, test cases are just inputs. So, you run the program on an input and you watch how it executes. Like, you see it executes this system call, that system call. It covers these branches. And you use that to learn a new behavior or guess a new input. And then the fuzzer will use a heuristic to pick that new input, with the idea it should trigger a new behavior.

    Ashley: Step back just for a moment, you’ve talked a little bit about Mayhem and the technology behind it. You’ve stepped out of CMU to set up this company, ForAllSecure. How did you get that started? Are you working with a particular private sector, government sector? Sounds like something that might be interesting to the government side of things, too.

    Brumley: Yeah, we got started by really participating in this, as I said, DARPA project. So, they have Grand Challenges every so often. One was the self-driving car contest. This was, like, a self-driving car for a computer security contest. We won that and that gave us our first $2 million, so that was, like, seed funding from the government.

    Ashley: Excellent! Wow, that’s awesome.

    Brumley: Yeah. And so, we’ve been working to bring it into the government so it’s used in pretty much every service and in the IC right now to try to look for vulnerabilities in weapons platforms as well as in software the government might be using to try to fix it before attackers can break into it.

    Ashley: Mm-hmm.

    Brumley: About, oh, six months ago, we then went and raised money from NEA to help transition this from just a government tool to something in the enterprise section as well.

    Ashley: Mm-hmm, so you’re also beginning to work with the private sector, then?

    Brumley: Yeah, we’re working—starting to work with the private sector. It’s really kind of an interesting difference between the two.

    Ashley: Oh, there’s a lot of difference. [Laughter] Yes. Highlight what you see the difference as. I have some experience with both, also.

    Brumley: Well, I think that the private sector, it’s harder for them to put a value on finding a vulnerability and fixing it quickly while, in the DoD, it’s really easy. That mission didn’t succeed, which is a big deal.

    Ashley: Mm-hmm.

    Brumley: So, I think that’s one difference. I think the second difference as we see going to market is, in the DoD, they care a lot about checking legacy systems, because they still have to maintain them. And if you think about it, lots of vehicles, airplanes, trains—things like that. And in an enterprise, they care about things that were developed in the last two or three years only. And so, they’re just kind of products in different parts of the life cycle.

    Ashley: Yeah, interesting. You also have many layers of different parties involved in the government sector—contractors, subcontractors, primes, et cetera. So, you’re dealing with lots of layers of companies that are working as part of the government team.

    Brumley: Yeah, working with the government is definitely, it’s a chore until you get into the groove and you realize a lot of the, what you perceive are barriers, are actually just regulations put up to protect taxpayers from complete abuse. So, it takes a long time, it takes about nine months to get anything really going from start to scratch in the government. But once you kind of get that cycle, it goes forward pretty quick.

    Ashley: Yeah, that was my experience, too. It’s an investment, but once you get going, it’s great.

    Brumley: Yeah.

    Ashley: So, talk a little bit about where you are in the product life cycle? Do you have product in the market? Is Mayhem publicly available? Are you alpha, beta? Give us an idea of that.

    Brumley: Yeah. So, within the DoD space, we have Mayhem that you can buy starting in July this year—so, pretty close. So, we have a number of beta installs, people are happy, and we’re gonna be switching over to general availability pretty quick.

    Ashley: Mm-hmm.

    Brumley: In the commercial market, we’re taking it a little bit slower, because some of these differences I’ve discussed. They use different application stacks, they’re often concerned with much newer software than old software, they often use different languages.

    And so, that, we’re looking for design partners. People who wanna take Mayhem, what’s working in the DoD, what’s working in places like aerospace, and see if it works for them and figure out what we need to do to make it a really good fit.

    Ashley: Mm-hmm. So, you’re spending a lot of time with customers and potential customers really learning what the commercial sector is looking for or can benefit from.

    Brumley: We’re learning what they’re looking for. We’re also trying to understand, like you said, when you go to market, it’s kind of interesting in the DoD who the buyer and who the user are and trying to understand that in the commercial space. Like, it’s kind of fascinating to me in DevSecOps, it’s almost always the security team that’s the buyer but it’s the development team that’s the user.

    Ashley: Mm-hmm. Yeah, exactly. And that’s an interesting dynamic there, it’s, you know, the DevSecOps conversation, one that we helped facilitate bringing together through a lot of the activities at devopsy.kinsta.cloud.

    I’d love to hear a little bit about, so you said you’re not commercially available yet in the commercial or private sector, but you are entertaining companies to work with? Is that true?

    Brumley: That is. So, we’ve worked with a large aerospace vendor that makes airplanes. Can’t say much about that. We’ve been able to really help them find some flaws in some software that they use as well as build up test suites for them so that when the developer does push a fix, that can be more rigorously tested, working with a Fortune 100 company, and then some IT infrastructure people.

    Ashley: Mm-hmm. I could see, for example, data center providers being another place that it’s gonna really benefit from.

    Brumley: Oh, absolutely. Anyone who has something that’s extremely high value like a web server that, if it gets compromised, your entire business is at stake.

    Ashley: I’d love to hear your thoughts about how you fit this into the DevOps or the DevSecOps pattern or cycle. How does this happen? Where do you build it into?

    Brumley: Yeah, so, from what we can see in research right now in a lot of DevSecOps, it’s really kind of a primitive stage where people want to run a scan before they field software. To me, this is insane. I don’t know any attacker who runs a commercial product and a scan and then says, you know, “Here’s the new zero day” or, “Oh, better not go after that, the scan was okay.”

    Instead, what they do is, they’re always trying to break into that software. They’re always trying to learn from what hasn’t succeeded and come up with attacks and succeed. So, Mayhem is like that. So, the idea is, it’s more of asynchronous testing. You’re gonna push as part of your DevOps cycle through, you know, things like making sure you’re not using old versions of libraries. But then, you’re gonna launch a process that, for the lifetime of that product, tries to hack it in the background.

    I think that’s really kind of the conceptual shift that we think needs to be made is to stop thinking of security as a scan you do once, and actually expect it to work, to something that’s always going on in the background.

    Ashley: I’m gonna shift just like we do with testing, we’ve moved into continuous improvement, continuous testing do the same for DevSecOps where this is running maybe on multiple versions of the product and test environment all the time.

    Brumley: Absolutely, as well as all the dependencies. If you look at Google—so, Google runs fuzzing, one of the technologies that I talked about earlier, on Google Chrome. And they found 12,000 new vulnerabilities in the last three years, and each one was accompanied by a test case, so zero false positives. And one of the things this has allowed them to do is get ahead of attackers, because they’re finding those flaws so quickly with their automated, always on infrastructure that I’ve talked to people who try to participate in bug bounties. And by the time they report it, it’s already fixed.

    Ashley: Mm-hmm. I mean, aren’t the bad guys also doing fuzzing themselves, so you’re at a disadvantage if you’re not?

    Brumley: Absolutely. Every top notch hacker I know uses fuzzing extensively as one of their techniques. I mean, this is assuming you kind of do the base, like, did the person forget to set a password? Always check for that first, right? But after that, after that base level, you’re gonna do fuzzing, especially after high value targets.

    Ashley: Talk a little bit about where you see things going next. You’re kinda testing with the commercial market, you’re heavily engaged with the federal market. What happens next in terms of the product roadmap?

    Brumley: Well, the next question that we have in terms of the product roadmap is, how do we close that life cycle from finding a vulnerability to having a fix fielded. So, some app site companies, what they wanna do is always add on that next language support so that they can support a larger and larger set of languages.

    Ashley: Mm-hmm.

    Brumley: For us, we’re really looking at C, C++, Java, Python—the core languages used by infrastructure Go and Rust. And we want to be able to do deep analysis in these languages and then be able to help automatically suggest fixes and actually, for DARPA, we proved that the computers could automatically patch. So, it could automatically patch binary programs, and it could assess whether that patch would have any business impact, and field it, if not. And so, that’s really what we’re trying to do, and we’re going language by language as opposed to trying to cover all the languages at once.

    Ashley: Interesting. What’s your top pick in terms of languages you’re looking at first?

    Brumley: So, the top one that we started with is C and C++. And that’s been a bit surprising to people, because it’s an older language. I can tell you why we picked it.

    Ashley: Okay.

    Brumley: The reason that we picked it is, regardless of what language you choose, you’re gonna be calling out to C and C++ code. In Java, you have JNI calls. In Python, you have, you know, as part of TensorFlow, if you’re doing machine language, everyone goes to C/C++ or a compiled language when they want performance.

    And so, if you wanna analyze these applications completely, even if it’s Java or Python, you have to be able to analyze those components as well. So, we’re kind of working our way up.

    Ashley: Yeah, I was gonna say, it sounds like you’re working way up the stack into the scripting languages.

    Brumley: Absolutely. The second reason is, when you look at really critical infrastructure out there, it’s still primarily developed in C and C++. So, you know, I, like many people, have probably put up a Flask or Python website, it’s really quick to do, it’s online—you definitely don’t want it hacked. But when you start talking about a car or an airplane or a power plant—these are also on C/C++. And so, just from a safety point of view, you have to cover those.

    Ashley: Interesting. Do you foresee, looking kinda down the road—I’m not asking you to announce anything officially, but do you see that you might be working with either the patch management companies, the vulnerability scanning companies as a complement to them? Would this be something that potentially displaces them? How do you see that future unfolding?

    Brumley: Yeah, I think people who detect known vulnerabilities are complementary to us. So, the way I think of it is, there’s really two types of security companies out there. There are those who find new vulnerabilities, and there’s those who check for old vulnerabilities.

    So, you have, for example, Tenable, which is a network scanner that goes and looks for known vulnerabilities. You have software component analysis, which looks for known vulnerable versions of libraries and other things, right? So, those are pattern matchers in some sense.

    We’re not one of those companies. That’s someone that you would partner with. What we’re doing is, we’re finding new vulnerabilities. And so, this is more like a typical SaaS or DaaS type solution.

    The other sort of people that we’re looking to partner with are the patch management. So, one of the cool things that we can do is, when we find a vulnerability, we automatically are building a test suite as well, just part of the process. So, when there’s a patch we can replay it, and we can tell you things like, “Hey, have any of the previously passing test cases stopped working? Has performance dropped?” as well as, of course, where the bug’s fixed.

    Ashley: I definitely can see the partnership alignment there. If you had to paint a future of what success looks like for, both for you and ForAllSecure, what would that be?

    Brumley: I think we’re really motivated by this vision that we wanna automatically protect and check the world’s software. And so, we wanna close that cycle and make it autonomous. And we’re making, actually, pretty careful design decisions as we do that.

    So, I think a lot of people talk about, you know, big startups, billion dollar businesses—that’s not really our goal. Our goal is, we want to make it so the time from when we detect a vulnerability to there’s a patch that’s tested and ready to field is seconds. That, to us, is success.

    Ashley: The billions will come later, right? [Laughter] That’s if you’re passionate about that core problem.

    Brumley: I think so. Because this problem, we were talking about DevSecOps. Like, DevSecOps, the problems facing DevSecOps face every system administrator if we go back in the world. In Silicon Valley, we think of SREs and DevSecOps, but there’s this huge nation full of just system administrators who wanna know, “If I update it, is it gonna break? Do I need to update it?” And solving those problems for those people is what’s important for us.

    Ashley: Do you have any demonstrations coming up, either online or you’re gonna be at some conferences? Is there a way for folks to see this yet?

    Brumley: Yeah, so, we’re gonna be at Black Hat and we’re happy to demo it there. We’ll have a booth and a room. We also have a number of online videos. If you want to see the fully autonomous, in its splendor system, there’s definitely videos of the DARPA Cyber Grand Challenge as well.

    Ashley: Going back to the original challenge.

    Brumley: That was the original vision. I mean, when I talk to people about this technology, what really lights up their eyes is not finding security bugs, it’s that there’s not enough people to do the work. And by being autonomous and focusing on that value proposition, you’re really focusing on the pain point, which is, how do I do things that there’s just not enough highly skilled people to do.

    Ashley: Well, I applaud you for what you’re doing. You know, there’s yet another scanner, yet another anti-virus something. It’s great to see folks that are really doing some innovation, kinda thinking about the problem differently and really trying to solve it in a more systemic way, and that’s one of the things that I see that you’re doing. It isn’t just, we’re trying to test for these kind of behaviors, but it’s also in this ecosystem of how patches happen and things can happen dynamically, automatically.

    Brumley: Absolutely. I mean, we’ve had a number of customers who want us to support 10 different languages, but there’s no product in the world that can add 10 languages to support and also be really good at each one of them. For us, our main value proposition is, for everything we do, can we have zero false positives, can we make sure it’s actionable before we report it at all?

    Ashley: Awesome! Well, we’re—[Laughter] the time always flies by on these podcasts. Is there any last parting thoughts that you wanna share with us before we wrap up?

    Brumley: Well, thank you for having me and, as I said, we’d love to talk to you at Black Hat 2019.

    Ashley: Great, great. Well, I’ll be there as well, so we’ll get to meet up there. We’d love to have you on a future podcast as things develop and hear more about how things are moving along for you and ForAllSecure.

    Brumley: Thank you very much. Have a great day.

    Ashley: Well, another DevOps Chat podcast has flown by, as they always do. I’d like to thank David Brumley, CEO, at ForAllSecure for joining us today. Thank you, David.

    Brumley: Thank you.

    Ashley: And I’d like to thank you—you, our listeners—for joining us, of course. This is Mitch Ashley with devopsy.kinsta.cloud. You’ve listened to another DevOps Chat. Thank you for joining us today.

    — Mitchell Ashley

  • DevOps Chat: Chaos Testing With xMatters

    DevOps Chat: Chaos Testing With xMatters

    Introducing chaotic, unpredictable test software into your methodical testing regime is a good idea, right? Yes, it’s a branch of testing called Chaos Engineering, or Chaos Testing. Netflix’s Chaos Monkey famously introduced many of us to the idea that resilient systems, networks and software become more resilient and less brittle if we use chaotic testing methods to find their weak points before customers do.

    An innovative engineer at xMatters launched a new open source chaos testing tool named after H.P. Lovecraft’s nightmarish character Cthulhu. Cthulhu is designed to test across multiple cloud providers, initially supporting Google Cloud with plans to support Amazon Web Services. It’s open source, free to use, looking for more contributors, and is available on GitHub.

    We are joined on this DevOps Chats by Tobias Dunn-Krahn, CTO, and Gabrielle Gasse, lead engineer on the Cthulhu open source project, both at xMatters.

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

    Transcript

    Mitch Ashley: Hi, everyone. This is Mitch Ashley, with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by Tobias Dunn-Krahn, who is CTO at xMatters, and also Gabrielle Gasse who is lead engineer of a software project we’re gonna talk about called Cthulhu, and that’s our topic today is Cthulhu.

    Now, if you’ve read the H. P. Lovecraft books, you know at least the fictional character that we’re talking about, but we’re gonna get into this software and find out a little bit more about what it does.

    Tobias, Gabrielle—welcome to DevOps Chat.

    Tobias Dunn-Krahn: Thank you.

    Ashley: Well, let’s start by introducing yourselves. How about you, Tobias, if you would start, just introduce—tell us a little bit about yourself, what xMatters does, what you do there as CTO.

    Dunn-Krahn: Sure. So, right, my name is Tobias Dunn-Krahn, CTO at xMatters. What that entails is purview for development operations, quality and product strategy. So, that’s my role.

    What does xMatters do? xMatters is a digital services availability platform. What that means in a practical sense is that xMatters helps teams that are responsible for digital services provide a high level of up time and reliability for those services. So, what that means is filtering unwanted signals for those services, engaging resolvers when those signals are relevant, facilitating collaboration during the resolution of an incident and, as well, integrating tools in a tool chain to eliminate any manual effort that’s involved in resolving an incident so that it can be done in a very timely fashion.

    So, that’s what xMatters does in a nutshell, and what I do there.

    Ashley: Interesting, yeah. I’m interested to see how Cthulhu fits into that. Gabrielle, would you introduce yourself and tell us a little bit about what you do at xMatters?

    Gabrielle Gasse: Yeah, of course. So, I’m the lead engineer working on Cthulhu, our chaos testing tool. On a day to day basis, I’m also just a Java developer working on the system itself.

    When I came into the company about a year ago, I was tasked to verify the resiliency of our system as we moved it to Google Cloud. And so, I did some research on existing tools and realized that we need something a bit different that was available already. And so, that’s how I came to start building Cthulhu.

    As—this is not the core product of xMatters, and we do want to promote the use of chaos engineering as a day to day practice for everyone, we decided to release the tool itself in open source.

    Ashley: Great. Maybe we should start with that, for folks that don’t know what chaos engineering or the theory behind it is, do you wanna say a little bit about that, Gabrielle?

    Gasse: Of course. So, the idea behind chaos engineering, if you think of a distributed system made of multiple microservices, you may end up with a fairly large amount of small VMs or containers running in parallel. And, as things are deployed in the cloud, sometimes failure happens. It always happens.

    And so, chaos engineering takes that as a premise, and it says that if you expect to fail all the time, then you will build your software with resilience in mind so that failure is not a problem. And so, this is where the idea of chaos engineering comes from. And so, a tool like Cthulhu is something that will run in our system that introduced outages so that we can verify that our system detects those issues and in some case—in most cases, ideally—recover, programmatically or thematically from those failures so that we don’t need to page one of our engineers at 3 a.m.

    Ashley: Tobias, is this a project or an idea that you came up with or you and Gabrielle did it together, Gabrielle came to you, or how did this all get started at xMatters?

    Dunn-Krahn: No, I will claim no credit for this project. [Laughter] I will hand that completely to Gabrielle. But another way of looking at that is, as we decomposed our monolith over time into microservices, what we really wanted to do was reduce the scope of subject matter expertise and knowledge amongst our teams to focus that on a smaller part of our system. So, that reduces complexity for individual teams and being able to keep those services up and running and highly reliable.

    But one of the things that it also introduces is, it chases that complexity into the space between the services—different failure modes of those services, different complexities around the dependencies.

    So, during our digital transformation we recognized that early on, and Gabrielle came up with the idea of introducing chaos testing for this and also that the existing chaos testing tools were not suited for our purposes, and I’ll let her explain how Cthulhu was different.

    Ashley: Okay, great. Gabrielle, why don’t you pick it up from there?

    Gasse: Yes. So, a year ago, when we started working on chaos engineering, there was a few tools that was available. Chaos Monkey is a very popular one. At the time, Chaos Monkey was working for Amazon Web Service primarily, and also it’s in deployment in Spinnaker. But it didn’t work for us, and so, we’re on Google Cloud.

    We came up with this tool that can connect to lots of different cloud services—currently, we support Google Cloud and Kubernetes, but we’re adding other services like Amazon Web Service, for example. And so, it can run those failure scenarios in concert together, and also, we wanted to have the ability to version control those tests so that when we find a particular scenario that does cause a failure, we could have a way to produce it as a file, if you like, that we could then attach to a bug that we could give to the engineer to work on.

    Ashley: Let me ask, then, you mentioned Chaos Monkey, which to me, was sort of a natural comparison for what you’re doing—does Cthulhu run in the background, kinda running all the time, creating its havoc, much like Chaos Monkey does of getting things to go down and see if they recover in a production environment? Is it similar for Cthulhu or are you taking a little bit of a different approach?

    Gasse: It is similar, although there is a different way to run it. In usual scenarios at xMatters, we are running it on a need basis. So, we have a small scenario that we’ll run immediately. It’s also possible to run Cthulhu, as you mentioned, in the background and it will pick up tests and run them, essentially.

    Ashley: Mm-hmm. So, run it in a targeted control manner, or let it run in the background and do its thing, it can go either way?

    Gasse: Yeah, exactly. The thought was very much to have this ability to run it constantly like Chaos Monkey, but also give a tool for an engineer to perform a scenario locally or in a development environment to try and reproduce and understand failures.

    Ashley: And you mentioned, of course, Chaos Monkey was created by Amazon Web Services, functions very well within an AWS environment—was multiple cloud services the main differentiator for Cthulhu, or was also getting into Kubernetes, Docker, Containers something that you kinda took on as a special added functionality that Cthulhu does that maybe another tool doesn’t? What are all of the differentiators that you’ve created Cthulhu for?

    Gasse: Chaos Monkey was actually created by Netflix, who have their stack on Amazon Web Services.

    Ashley: Oh, you’re right. Yeah, my mistake—thanks for correcting me.

    Gasse: But, as you mentioned, Chaos Monkey works on a virtual machine in Amazon Web Service exclusively. There are other tools like Pumba that works at the Docker Container level. Powerful Seal came out last year around the time that we were looking at that, and Powerful Seal works on Kubernetes deployment at the pod, but also at the node level, which is pretty interesting.

    But there’s no one system that will do—that will test across all of those platforms. You need to use Powerful Seal in concert with Pumba, and there was nothing that was running directly on Google Cloud at the time. Now, Chaos Monkey does support Google Cloud.

    So, the main value that Cthulhu brought for us was the ability to have a single tool that could perform complex failure scenarios across both our Kubernetes deployments and our VMs. And—yeah, and we wanted, also, the ability, as I mentioned earlier, to version control some of those tests so that we could pass them on to our developer where Chaos Monkey and those other tools, you run them with some parameters to filter out certain machines that you don’t want it to break. And then it just rolls from there. There’s nothing—there’s no way to build a scenario from it that is repeatable.

    Part of what we test with it is that our system is able to detect failures. So, as we run a scenario, we’re expecting errors to be logged in Splunk alerts to be sent out to us. And so, the tool itself simply introduced failures, and then it’s up to the engineer to look for what is broken.

    Ashley: Mm-hmm, mm-hmm. Very good. Tobias, how does Cthulhu fit into the strategy of xMatters?

    Dunn-Krahn: So, we would—you know, our personal experience or our corporate experience of going through our own digital transformation was—and a continuing process, I don’t wanna make it sound like we’re done, we’re never done. But it was very instructive, and we learned a lot, and we’d like to share that. And many of our customers are going through the same thing, so we would like to provide them the tools that they need to be successful in these transformations.

    So, Cthulhu in particular aids in the transition process more than what you would—the situation you’d be in if you were a Cloud Native company. So, we wanted to provide that support to our customers and to the community at large. We have long been  users of open source software, and we wanted to contribute back to the community as well as get all the advantages of having an extended developer community contributing to Cthulhu and we can all make it better together.

    Ashley: Great. So, Cthulhu is an open source project. Do you have it hosted at GitHub or your own servers? Where do people find it?

    Dunn-Krahn: Gabrielle, you can confirm, but I believe it’s on GitHub.

    Gasse: That’s correct, yes.

    Ashley: Great. You know, sometimes open source projects are open, but largely, most of the work is done by a lead developer or someone who created the idea. Sometimes, it’s a very vibrant community where people are testing or creating new features. You know, and part of that is also not only the style of the project but also the maturity of it.

    Where are you in that? Is it mostly you, Gabrielle, who’s doing the work? Do you have—what kinda activities do you have from the outside from other people?

    Gasse: Yeah, the publication of Cthulhu on GitHub is fairly recent. We’ve had a fair amount of people local to Victoria when we promoted it so far that are following the project, but we have yet to see people who are really picking up or starting the contributing modules for it.

    Ashley: Mm-hmm.

    Gasse: I think one of the next additions that will really help motivate people to use Cthulhu but also contribute additional modules will be us supporting Amazon Web Services in particular.

    Ashley: Mm-hmm. And how long has it been out? I should’ve asked that originally.

    Gasse: It’s been out for a few months, only.

    Ashley: Okay. So, still pretty early in its life. So, it’ll be interesting to see, as more people use it, that’s usually where someone will get interested and say, “Well, I wanna put some stuff in here. I wanna try to make some changes and contribute some things.” What’s Cthulhu written in?

    Gasse: Cthulhu is written in Java. We’re using the Spring Boot platform, and as part of that, there is an easy way to write modules that plugs into the platform that adds functionalities. So, it’s easy to add new ways to break things in Cthulhu without having to understand the entire code base.

    Ashley: What are other things that we should know about Cthulhu?

    Gasse: I can talk briefly about the next item on the roadmap, if—

    Ashley: That’d be great, yeah.

    Gasse: —yeah.

    Ashley: Sure—love to hear that.

    Gasse: Mm-hmm. So, after the support for AWS is done, my next task, if you like, is to start adding a functionality to run commands through SSH and sending files through SCP on target hosts. And that opens the door to a whole new range of tests. For example, one could pause a process on the target virtual machine to simulate a dead live or use tools like Traffic Control to introduce noise on the network, lost packets and all that.

    And so, once we have that support, we’ll really be able to have lots of interesting types of failure that go beyond simply just, a virtual machine has shut down and is no longer available.

    Ashley: Tobias, I appreciate very much you handing all the credit where credit is due to Gabrielle. Also appreciate your thoughts on where do you see this going from your perspective, either strategically or aligned with product plans, product strategy—what do you see as the future for Cthulhu?

    Dunn-Krahn: Sure. Well, as I mentioned earlier, the xMatters product is built to help teams support digital services, and part of that is making sure not only that you plan for an incident but that you can simulate real world incidents and do some form of practice or maneuvers.

    So, the way I see this being integrated into the product in the future is facilitating those types of practices and then evaluating the performance of the team or that all of the configuration in xMatters is correct to solve problems as quickly as possible, et cetera.

    Ashley: Excellent. Well, you know, we’ve probably just barely scratched the surface, and I’m excited to see what you all do and what the community does with Cthulhu. I’d love to thank you both for being on the podcast. I thank Tobias Dunn-Krahn and also Gabrielle Gasse from xMatters, any additional information might be available at xMatters, is that true, Tobias?

    Dunn-Krahn:  That’s a good question. Yes, there’s certainly some material on the website, or you can search for it on the web if you can figure out how to spell it.

    Ashley: [Laughter] Well, let me give everybody a head start, it’s C-T-H-U-L-H-U, so, just the way H. P. Lovecraft spelled it. Well, I’d like to thank both of you, Tobias and Gabrielle, for joining us today on the podcast. Time has flown by again, and hopefully, we can have you back another time as this evolves and you can tell us some more stories about where you’ve taken it and what people have done with Cthulhu.

    Dunn-Krahn: Alright. Thanks very much for having us.

    Ashley: You bet. Thank you. This is Mitch Ashley with devopsy.kinsta.cloud and you’ve listened to another DevOps Chat.

    — Mitchell Ashley

  • DevOps Chat: Global Intelligence for AWS GuardDuty, With Sumo Logic

    DevOps Chat: Global Intelligence for AWS GuardDuty, With Sumo Logic

    Wouldn’t it be helpful to know if other cloud users are seeing the same or similar attacks that you are? Security intelligence about cloud applications beyond just those you own and operate as an enterprise opens up a new dimension in attack visibility against even large sets of cloud apps.

    During AWS re:Inforce 2019, Sumo Logic announced it is extending its machine analytics and intelligence platform to include AWS GuardDuty. Dubbed Global Intelligence Service for Amazon GuardDuty, the new service is more than just a data aggregation and reporting play. The new service provides additional context around GuardDuty data by reporting attack information across multiple Sumo Logic customers using AWS GuardDuty. Essentially, it’s a “crowdsourcing” approach to reporting threat intelligence across the cloud.

    In this episode of DevOps Chat, David Andrejewski, senior engineering manager at Sumo Logic, joins us to talk about this new, more expansive threat intelligence service. More information about Global Intelligence Service for Amazon GuardDuty is available in the press release and website.

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

    Transcript

    Mitch Ashley: Hi, everybody, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, I’m joined by David Andrzejewski, Senior Engineering Manager at Sumo Logic, and our topic is a real meaty one—Global Intelligence Service for Amazon Guard Duty. David, welcome to DevOps Chat.

    David Andrzejewski: Thanks so much. Thanks for having me on.

    Ashley: Well, we really appreciate you being on the podcast today. Would you start by introducing yourself, just tell us a little bit about what yourself and what you do at Sumo Logic, and maybe just a brief overview of Sumo Logic the company?

    Andrzejewski: Yeah, fantastic. So, Sumo Logic, what we offer is a cloud-based machine data analytics platform, which is a bit of a mouthful, but what that specifically means is a cloud-based, multi-tenant service where you can send your logs and metrics and data to our service for helping you monitor, troubleshoot, and secure your applications, platform, environment, infrastructure for your own application or your IT infrastructure.

    So, we offer this as a kinda cloud-based web app service. The idea here is, you’re sending us all of that data and we can kind of manage the scale, reliability, and analysis for you and kinda help you focus on running your business and kind of running your app and everything like that.

    Specifically at Sumo Logic, I manage the Advanced Analytics Team, and we’re focused in particular on ways that we can do especially kind of useful or interesting things to help customers get more out of their data. So, some of the features in the past we’ve worked on are log reduce, which kind of applies clustering techniques to your logs to kind of give you a more comprehensible snapshot as well as outlier detection and things like this. But our current focus right now is this kind of Global Intelligence Service that we’re really excited to be announcing at AWS Reinforce.

    Ashley: Great. Well, we are a DevOps and also a security podcast—talk a little bit about how Sumo Logic fits into the DevOpsSec world.

    Andrzejewski: Yep, absolutely. So, ultimately, in any of these situations, you really need some kind of—you need the ground truth actual data to really kind of know what’s happening in your environment, both from what kinds of experience are your customers getting, how is the, kind of the health of your machines or what resources are available, what is the performance of various services, you know, events are being kind of logged and audited and then you’re kind of pulling data together from all up and down the stack into one place.

    And that’s kind of where we come in as sort of one kind of one-stop shop for sending all of these very kind of heterogeneous logs into one service such that the teams that are responsible for up time from kind of a DevOps SRE perspective and security from all sorts of aspects of that, which increasingly is, like you said, kind of this DevSecOps. The developers themselves are often increasingly deeply involved in all of that, where they can kind of pull together the data from their own kind of custom application logs, the infrastructure, the actual machines, the operating system, the firewall, the databases, the third party services and kind of have it all in one place so that when you can sort of help detect when things do go wrong and then kind of identify, dig in, troubleshoot what’s going wrong and then once you fix it, you know, verify that it actually is corrected.

    Ashley: Mm-hmm.

    Andrzejewski: So, you would interact with the service by sort of operating queries against your data, creating dashboards and visualizations and using these dashboards or potentially setting up alerts to notify members of your team that some condition has been triggered that requires immediate attention or action to generate sort of scheduled kind of reports on these kinda things and in general, kinda analyze and interact with the data, the raw data being kind of sent out by your software, your machines and everything like that to really understand what’s going on in your app.

    Ashley: And are you oftentimes the system in the SOC, or do you connect into a different monitoring system, alerting system in the SOC?

    Andrzejewski: So, this is kind of a—as far as the SOC aspect, some customers are kind of using it for tracking these different kind of logging events, others are sort of, we have a lot of kind of integrations with other services to kind of consume data kind of emitted by those services. So, for example, AWS Guard Duty, you know, alerts like that.

    So, it all kinda depends on, there’s sort of a wide variety of ways that customers have kinda made use of Sumo Logic. So, yeah, in some cases, I think that that’s a reasonable use case that the [Cross talk]—

    Ashley: It’s probably, I imagine, where they’re starting from if they have systems all ready for you to integrate in, or maybe you become the main single pane of glass, if you will.

    Andrzejewski: Yeah, so, in the security use case, I think—again, it depends on kind of which sort of person within the organization might be most interested in that. Developers often, you know, given that this is a place, a single sort of solution that you can collect the logs for both these kind of monitoring SRE troubleshooting as well as some of the security use cases.

    Ashley: Mm-hmm.

    Andrzejewski: That ends up being kind of an appealing property that you can kind of have one service to collect the data, analyze the data for various use cases, right?

    Ashley: Okay, great. Well, this is the week of AWS Reinforce, and I feel like we’ve kind of laid out enough teasers about your announcement that you’re making this week. [Laughter] Tell us about Global Intelligence Service for Amazon Guard Duty.

    Andrzejewski: Yeah, yeah, we’re really excited about this. So, the basic idea here is that we’re going to add some additional context around the Guard Duty alerts where we can essentially take your alerts and kind of recontextualize them in terms of how frequently we’re kind of seeing them or they’re being sent or observed across others.

    So, if something is a very kind of rare threat that very few other organizations are kind of getting, seeing in their environment, then that might be something that you would want to prioritize more highly, right, if you are—you know, there’s going to be some, in any kind of alerting system like Guard Duty or others, there’s often going to be a very kind of high just baseline of sort of very generic, general threats that everybody kind of sees at some base rate all the time, and this is kind of one way that you can sort of kind of do some noise reduction on those and really kind of prioritize and focus on the ones that are a little bit more idiosyncratic or unique to your environment and more, perhaps more interesting and more relevant for kind of immediate investigation and triage.

    And this is kind of being exposed to the customers via an app, which is kind of, in the Sumo Logic scenario, it’s kind of some pre-defined analyses and dashboards against your Guard Duty data. So, your customer would sort of consume this service by installing the new Guard Duty with Global Intelligence Services app, and they would immediately get access to these new visualizations, analyses, and dashboards that kind of place their own Guard Duty alerts in this modified context, this more—you know, bringing in a little bit broader information about how often these are being seen in other environments, what are the general most common threats, threat purposes, various threat types seen across sort of the general customer population at Sumo Logic.

    And this will sort of kind of serve these multiple purposes for the user—on one hand, helping you kind of prioritize rare events, on the other hand, kind of giving you sort of this bird’s eye view survey of what’s generally out there, right? And that can help potentially in prioritizing or allocating efforts at improving your own security posture or efforts in, for example, you see that a particular kind of threat is especially prevalent, you know, elsewhere, that might be something that you say, “Okay, well, what do we have to be doing to make sure that we’re, our bases are covered with respect to that ourselves,” right?

    So, ultimately, we want to kind of show you your AWS Guard Duty threat data, but in this kind of enhanced context that’s hopefully going to be more meaningful and more relevant to you and help you make better decisions and kind of run your business more securely.

    Ashley: Okay, so, the benchmarking aspect of this, is that something that happens in real time? You know, we’re looking at the console, we’re getting alerted to say, “This attack is happening, and by the way, it’s happening on 20 percent of the other AWS customers” or however your present it, or is it more a retrospective looking at past data of what’s occurred over the last month, last quarter, last year? Or is it both?

    Andrzejewski: Yeah, so, this is something that we’re kind of, in some sense, as we are having conversations with customers, seeing what’s going to be most valuable for their use cases. Right now, the real time—is it real time, like, up to the second? You know, is that really something that’s going to be valuable, or is that going to be kind of too noisy of a signal?

    Ashley: Mm-hmm.

    Andrzejewski: So, right now, it’s derived from sort of recent history in some sense, and yet, potentially, that’s an interesting question of whether more very long term stuff, like, month over month is going to be useful for people, but you know, is it—right now, we’re not kind of focused on the use case of, you know, up to kind of real time real time.

    Ashley: Mm-hmm.

    Andrzejewski: Really, your data will still be real time, real time, but the question of whether that’s—you know, does the context need to evolve that quickly, or is that just going to kind of introduce more noise?

    Ashley: Right.

    Andrzejewski: Part of the advantage of kind of using a little bit of a recent historical window is looking at—you know, it gives you a little bit broader pool of data to kind of contextualize your real time activity against, right? So, again, it’s all about sort of your data and kind of seeing how—you know, how it kind of looks in context of this broader view and evolving the broader view in real time. It’s an interesting thought.

    Ashley: Well, that makes sense, too, because you may be having a false positive or something. Not everything that is being highlighted by Guard Duty might be as relevant as other things, so if you have a chance to filter some of that information out to say, “This is what’s relevant” versus, if everything’s real time, you could introduce some noise, maybe some things that aren’t as helpful, too.

    Andrzejewski: Yep. Yeah, exactly. So, it’s—that’s definitely a potential tradeoff, there.

    Ashley: So, what would you learn—because now, there must be some kind of an opt-in where you’re looking at events that are happening across different customers, AWS users—what would you learn by knowing that a whole other population of people are seeing this same kind of attack versus if you were only looking at your data, if you had known that you would do something differently?

    What would be a scenario like that where this would be super helpful?

    Andrzejewski: Right, so, the—you know, one kind of particular case sort of going the other way of a rare event might be that, you know, again, so, some of these threats are going to be very kind of common, and it ends up that that’s not something quite as potentially actionable or something that you need to jump on right away, but there’s still kind of part of your Guard Duty feed and they’re going to kind of potentially be a little overwhelming when you’re looking at everything. Whereas this more kind of like rare threat type, this—by kind of knowing, “Okay, this is a little bit out of the ordinary in that lots of customers are not seeing this,” that kinda helps it pop to the top of your queue and maybe you are going to allocate your very limited time and attention to focus on that.

    It might be a little more challenging to prioritize or see that kind of rare event pop, because you don’t necessarily know that it’s rare, you just sort of see it amongst all of the other kind of more common alerts and more common threats.

    Ashley: Right. This is a rare event, something that’s unusual, you should take a look at this versus something that’s happening normally across multiple AWS accounts.

    Andrzejewski: Exactly. That’s exactly right. And so, that potentially becomes a valuable tool to kind of—like I said, ultimately, teams everywhere are ultimately struggling with the scarce resource of your time and attention.

    Ashley: Mm-hmm.

    Andrzejewski: And anything that can kind of bring in some additional context information to help you allocate that time and attention more efficiently, more effectively is potentially, hopefully going to give some good value for our customers.

    Ashley: Well, many resources are precious resources, and certainly security folks are definitely in that precious category. So, being able to assign them to something you know is something we need to look at versus kinda chasing things that we really don’t need to be paying attention to would be super valuable.

    Andrzejewski: Absolutely.

    Ashley: So, obviously, Sumo Logic does a lot of other things in your products. You have operational analytics, business analytics, those kinds of things. Does this Global Intelligence Service tie into those in some way, to give you some additional broader insights, or this focused really—just really heavily on the security aspect of what’s happening in Guard Duty?

    Andrzejewski: No, absolutely—that’s a really good point. So, right now, kind of, very sort of aligned with Global Intelligence is some of the stuff that we’ve been doing a few years now around the modern app report and similar where kind of giving these sort of horizontal views of technology choice trends and various kind of software choices, infrastructure, cloud provider choices, kind of adoption of various tools and technologies across the industry, and that definitely kind of extends into the, kind of the DevOps SRE space. And again, hopefully the idea there is that these tools kinda give you this sort of broader context about actual hard data where various—you know, where the market in general is on their journey to cloud adoption or their migration to Docker or Kubernetes or other kind of related technologies.

    Ashley: Mm-hmm.

    Andrzejewski: So, that’s one place where there’s already something in place at Sumo Logic that’s kind of bringing that broader sort of horizontal context to bear to kind of help teams kinda make more effective, more informed decisions and, again, prioritize and allocate their attention and efforts in kind of using that extra information to kind of know, actually, from the hard data where others are actually at.

    Ashley: Mm-hmm.

    Andrzejewski: So, right now, this particular announcement at AWS Reinforce is focused on Global Intelligence Services for AWS Guard Duty in particular which, as you said, is absolutely a very kind of security focused use case.

    Ashley: Mm-hmm.

    Andrzejewski: But in general, the general sort of Global Intelligence Services, you know, kind of platform and approach is something that we’re also actively thinking about how can we help in the operational analytics use cases? Where are there places where that broader context is going to help our customers make better decisions or solve their problems more quickly?

    So, right now, we have this Guard Duty announcement, definitely focused on security, but in general, we see Global Intelligence Services as a very powerful kind of horizontal enabler across the SRE DevOps kind of side of the house as well.

    Ashley: Mm-hmm. Yeah, it seems like an area that would be ripe for machine learning—yeah, the statistical analysis that you could do across multiple areas of the analytics that you’re doing. You know, that’s what data’s all about, right? What insights and learnings can you get from that that brings additional value benefit to the business?

    Andrzejewski: Definitely, yep.

    Ashley: Well, good. Is this product available now? Is it coming out some time down the road? How soon can we get our hands on this?

    Andrzejewski: So, as of the kind of announcement, it should be available to Sumo Logic customers at the enterprise level, and again, it would be a matter of installing the app and kind of start—obviously, in this case, you would need Guard Duty as well. I can provide some links to go out with this, if that’s helpful—

    Ashley: Sure.

    Andrzejewski: – that would have kind of links to the specific resources that would be involved in getting started and getting set up with this, but yeah.

    Ashley: Okay, great. It sounds like a pretty easy thing to do to get started. If you’re already running Sumo Logic, installing the app is not a heavy lift, it’s pretty straightforward.

    Andrzejewski: Absolutely. And the other aspect, of course, having Guard Duty in place as well. Which, again, is—in the links I’ll send, should be, is a pretty painless process.

    Ashley: Excellent! I also want to mention, too, that Sumo Logic is located in Booth 714 at the Reinforce conference. So, definitely recommend folks stop by and maybe see a demo of this, get to talk with folks about the new announcement.

    Well, our podcasts have no problem flying by quickly, because we talked about great things and I appreciate you doing that with us. David, I’d like to thank you, David Andrzejewski, Senior Engineering Manager at Sumo Logic, for joining us.

    Andrzejewski: Well, thank you so much for having me. It’s been a really great conversation—super, super interesting to talk about.

    Ashley: Great. It’s good stuff, and I wish you and Sumo Logic the best at the show this week.

    I’d like to also thank you—you, our listeners—for joining us. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat. Be careful out there.

    — Mitchell Ashley

  • DevOps Chat: ‘War, Peace & IT’ With Marc Schwartz

    DevOps Chat: ‘War, Peace & IT’ With Marc Schwartz

    Marc Schwartz is one of those rare individuals who is not only a great IT exec, but he also can analyze what works and doesn’t work and write it up in a way that helps others. His “A Seat at the Table” is still one of my favorite DevOps books.

    Marc’s new book is called, “War, Peace & IT.” You can download an excerpt of it here: dl.orangedox.com/WarPeaceITExcerpt

    In this DevOps Chat, we speak with Marc about the book and some of the lessons behind it. Have a listen and check out the book ASAP.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel for devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. I’m really delighted to have as my guest on DevOps Chat today none other than Marc Schwartz. Marc, if you don’t know, is an AWS executive, multiple author on some of the greatest books on DevOps you’re gonna read—”A Seat at the Table” is still one of my all-time favorites—and I think as he’s described in the latest blurb on IT Revolution, an iconoclastic CIO.

    Marc, welcome to DevOps Chat.

    Marc Schwartz: [Laughter] Thanks. I’m glad to be here.

    Shimel: So, Marc, what is an iconoclastic CIO?

    Schwartz: [Laughter] I like to question assumptions. You know, I find that, very often, people are frustrated. There are obstacles to what they’re trying to accomplish, and the problem is that they’re constrained in all sorts of ways, and if you don’t question the assumptions and knock away some of those constraints, they’re gonna continue to be frustrated—so, that’s what I’m all about.

    Shimel: Yep. I agree. So, I don’t want to spend a lot of time, but Marc, we mentioned you’re from AWS, but I didn’t really mention a role. Just so our audience, who may not be familiar—what currently is your role with AWS?

    Schwartz: They call me an enterprise strategist, and what means is, I’m part of a small team of ex-IT leaders, many of us ex-CIOs or CTOs of large enterprises who did digital transformation, moved to the cloud, and what we do now is, we work with executives from large enterprises to help them overcome some of the challenges that they face as they’re trying to do a transformation.

    So, often, it’s things like cultural change, or organizational change, or organizational structure, financing models, people skills, things like that. And we speak at conferences, we write books and blogs and we work with individual customers.

    Shimel: Very cool. No, let’s jump in, Marc. You’ve got a new book, just recently came out. It’s available on Amazon, by the way, in case anyone is interested, as well as Barnes and Noble, 800-CEO-READ, Indiebound, BAM and any other place where you can find decent books. It’s called “War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age.”

    Marc, share with our audience—what’s the book about?

    Schwartz: Well, the book is essentially an answer to a challenge that people gave me after they read “A Seat at the Table.” Because, in “A Seat at the Table,” it was written primarily for IT leaders, and throughout that book, I made the argument that we needed to get rid of this business versus IT distinction, you know? The way we talk about the business and IT as if it’s two separate things, the way that we see IT as taking requirements from a business and executing on those requirements, but that way of thinking is no longer effective. We need to find a way to bring IT into the business itself.

    And people responded very well to that message in “A Seat at the Table,” but they said, “This doesn’t work unless somebody tells the business folks the same thing, you know? [Laughter] We can’t just change the relationship ourselves. So, somebody should write a book for the business executives to explain to them what you’re talking about.” And I realized that that same book, if I could write it, would also help a lot of the executives that I was talking to as part of my job who were facing impediments to their transformations.

    So, I wrote a book that essentially said, “One of the big impediments to your transformation is that the relationship between the business and IT is not the right relationship, and here’s how you can change it, and here’s why it will make a big difference for you.”

    Shimel: Excellent. So, you know, I think you laid it out pretty well there, Marc, for people. You know, I’m just back—we were talking offline and I told you I was at a KubeCon + CloudNativeCon in Barcelona last week and it was another great event, 7,500 people.

    And what really kinda hit me square between the eyes was the fact that though this is a fairly technical event, right? We’re talking about cloud native and a lot of open source software programs and ops procedures, the business angle of it, the amount of business people who are there trying to get smart about what’s the latest trends, what’s the wave, if you will, in IT, and how could they leverage things like serverless or Kubernetes and some of these newer things to make their business better, not necessarily because it’s cool or, you know, shiny trinket syndrome or anything like that.

    But really, how does—when does rubber meet the road with this technology? And, you know, I can’t help—I mean, I’m heartened by it, Mark, but I still don’t know if business executives are all bought into that.

    Schwartz: Yeah.

    Shimel: Your thoughts?

    Schwartz: Well, I don’t think it’s about the cloud, per se, or DevOps or whatever it is. What really is important is how the cloud and DevOps and new ways of doing IT empower businesses to do new things that they couldn’t do before. And I think that’s what the non-IT business executives need to learn about what’s possible now that was not possible before.

    And the reason why they have to, why it’s an urgent matter is because their competitors are, you know? Whatever tools you have available to you, your competitors also have, and if you’re not using them, and your competitor is, then you’re at a business disadvantage. And I think mostly, it comes down to a question of speed, one way or another. So, using the cloud well, using DevOps well, lets you move at a much faster pace to get IT capabilities to change your business.

    And that pace is important not just for the obvious reasons that you need time to market, you need to get first mover advantages, you need to respond quickly when you competitors disrupt you, but also for more subtle reasons, because we now use speed as a way to test out ideas quickly and see if they’re gonna work, and manage our risk by testing out ideas before we fully commit to them, and we use speed to get feedback from customers and users and alter our product offerings based on what we’re able to learn, and we use speed to mitigate risk to improve our security posture, to improve our availability of systems.

    So, speed becomes a really important factor, and the cloud, DevOps, you know, their technical implementations, but they happen to help companies achieve speed, and that’s the important message, I think, that executives need to take away.

    [su_pullquote align=”right” class=”do_blockquote”]I don’t think it’s about the cloud, per se, or DevOps or whatever it is. What really is important is how the cloud and DevOps and new ways of doing IT empower businesses to do new things that they couldn’t do before.[/su_pullquote]
    Shimel: I agree. But, you know, there’s an old saying—speed can kill. Great speed kills, too, right?

    Schwartz: [Laughter] Well, if you’re using the right model for speed, it doesn’t kill, and the reason for that is that the models that use speed usually also use automated controls or guardrails. So, what you want, and the idea is, you want to be able to move really quickly, but within the boundaries of guardrails that enforce compliance, enforce security, enforce quality and it’s possible to do both. We always thought, in the past, that there was this trade-off between speed and stability or speed and quality, and it turns out that, in this DevOps world, in this cloud world, speed—increased speed actually increases quality, resilience, availability, security and all of those things. It’s a question of learning how to use speed for those purposes.

    Shimel: Yeah. And that’s really—I mean, tongue in cheek, speed kills. What I was really trying to get at is, speed for speed’s sake alone is, you know, speed has to be wielded—with great power comes great responsibility, right?

    Schwartz: [Laughter] Yes. You have to achieve the speed for competitive reasons and for business model reasons, as I was saying before. So, it’s not really an option, but you do, at the same time, have to learn how to use that speed as a way to reduce risks and improve the quality of what you’re offering.

    Shimel: Exactly, exactly. So, what’s the reception been, Marc? What kind of feedback have you been getting from people?

    Schwartz: Well, the book was just published a couple of weeks ago, really. Where are we? Yeah, May 14th was the publication date, so a couple of weeks. And people seem to be enjoying it. I was a little bit playful in writing the book, and I think there are some aspects of it that are entertaining people, and that makes me feel very good.

    But from the feedback that I’ve been getting, people are seeing it as the successor to that previous book, just as I had hoped. You know, this is the way of looking at a similar message, but very much from the point of view of non-IT business executives. You know, how should the CFO be thinking about the new world, the new digital world, how should a CEO be thinking about it, how should the board of directors be thinking about it? And I’m very happy that people see it as valuable on that front, and a lot of people are saying, “Well, I’m gonna have my entire executive team read this, and it’s gonna stimulate some great discussions,” so I’m very happy about that.

    Shimel: That’s fantastic, great stuff. Let me bring in another aspect of it and get your thoughts on it, Marc. You know, we’ve heard a lot over the last, I’ve heard it maybe over the last year or 18 months—DevXOps, right? We have DevSecOps, DevBusOps, DevHROps—DevWhateverOps, right? DevXOps. And I think there’s a little bit of a reverse equation, here. Business leaders have to be more involved in IT and have to learn how to harness IT to further their businesses’ goals and delight customers, as you say, right?

    At the same time, we can take lessons from IT and things we’ve learned in IT with things like DevOps but not only DevOps. But IT has had, in a relatively short period of time, had a rather torturous road of self-improvement and of learning new things and evolving to things like DevOps that we see. What can businesses do—not harnessing IT, per se, but maybe saving some idiot taxes?

    Schwartz: [Laughter]

    Shimel: You know, from mistakes and lessons learned from IT and apply them to general business?

    Schwartz: Yeah. I think—I also joke about DevOps, DevSecOps, DevSecBizOps, DevSecFinBizOps—you know? You can keep adding to that.

    The real point is cross functional teams, right? DevOps meant we’re gonna have a cross functional team that has dev skills and ops skills, and at some point we realize that that set of skills is not quite enough, they also need to have security skills and you can keep adding to that infinitely, because the bottom line is that functional silos don’t work very well in a fast moving environment like we have in the digital world today. Functional silos slow down your response, they slow down your ability to innovate and grasp new opportunities and respond to change and things like that.

    So, that’s really what was behind the DevOps, DevXOps concept. And I think businesses find this, in general, that when you have functional silos and they operate as silos, you introduce waiting time when you pass things from one silo to another. You reduce innovation because each silo thinks of itself as having its own responsibility instead of joint responsibility for results.

    So, the lesson that I think everybody can take away from what’s happened in IT is that, to respond quickly in an environment where you need to respond quickly, you have to do away with silos and instead focus on cross-functional teams that [Background noise] objective. At least, that’s my biggest takeaway.

    Shimel: Sure, sure. [Background noise] I’m sorry, my machine’s—uh oh, here we go. You know, I’m on my, I’m not gonna give you the brand of the surface I’m on. There’s only one company that makes surfaces.

    Schwartz: [Laughter]

    Shimel: It’s on a roll of reminders.

    Schwartz: Excellent sound effects.

    Shimel: It doesn’t shut up, here. Look at this, this is—

    Schwartz: That’s okay, we could use some background music.

    Shimel: Yeah, I guess so. It’s happening—I don’t know if I like the rhythm, but anyway. [Laughter] So, Marc, a good question is—look, you’re globetrotting around the world evangelizing your AWS role and everything. And yet, you know, over the last, let’s say, three years, four years, you know, this is the third book, actually, isn’t it?

    Schwartz: Yeah. It’s the third one, and I’ve started to work on a fourth.

    Shimel: Can you give us a sneak preview of the fourth, or it’s too premature yet?

    Schwartz: Well, it is too premature. It can go in lots of different directions, but I can tell you what I’m thinking a lot about right now, which is bureaucracy and how to overcome it on the one hand, but even more than that, I think you can harness it in many ways, if you are trying to become a digital organization.

    And, you know, I think that fulfills my role as an iconoclast. I think bureaucracy is one of those words that people have a very strong negative reaction to. But, of course, in my role before AWS as a government CIO, I, of course, witnessed, experienced a lot of bureaucracy and developed strategies for coping with it that I think would be useful to a wide audience. So, I think I’ll probably write something that has to do with that.

    Shimel: Okay, pretty cool. And you know what? We mentioned “A Seat at the Table” and, you know, there’s nothing like your first book, but I feel amiss if we shouldn’t also mention the title of the second book, right, and that is “The Art of Business Value,” right?

    Schwartz: Yeah. “The Art of Business Value” was sort of my initial train of thought. You know, I said to myself, we’re talking a lot about business value and how important it is to guide what you do in the IT world by delivering business value and how you should make prioritization decisions by business value, and it occurred to me that nobody was really talking about what that meant, you know? What is business value, exactly?

    And when I looked into it, I realized that people were not really interpreting it, in many cases, in the best way, and that if you thought a little bit more deeply about that, it would change the way that you practiced IT.

    So, that was what drove that first book, and in that book, I introduced the question of what does a CIO have to do with figuring out what business value is? How does a CIO make sure that he or she is delivering business value? And I realized that that was a good topic for a second book, actually. [Laughter] Something that I really needed to dive more deeply into. So, that’s what generated “A Seat at the Table.”

    And then, as I said before, once I had written “A Seat at the Table,” it was sort of clear to me what the next thing had to be. It had to be the book that I hope will speak to non-IT business leaders. So, that explains the sequence of the three books in my head.

    Shimel: Very cool. So, Marc, is there a tour going on with the book? Are you out speaking—I mean, are you gonna be, for instance, at DOES: London, coming up?

    Schwartz: I will be there. I speak at a lot of conferences in my role with AWS, and so, I’m on a permanent tour, essentially. [Laughter] I speak all over the world, and of course, I write blog posts and I’ll be writing some more books. And it all ties together with my role at AWS, where I’m part of a team that’s trying to lead enterprise executives into the future. You know, here’s the way that we see things developing, here’s how you can take advantage of what’s going on with the cloud and with DevOps.

    And so, I don’t have a speaking tour specifically about my book, but a lot of the topics that the book touches are also the topics I talk about for AWS.

    Shimel: Great. Great, great, great. Marc, we’re about out of time. We mentioned you can get the book on Amazon. Up on devopsy.kinsta.cloud, I think we have a link to a, I don’t know if it’s the first chapter or an excerpt of the book. We’ll put that in the show notes.

    Look, man—first of all, congratulations on what sounds like another great book. I’m actually, I’m gonna be on the road a whole bunch in June, so, I’m gonna have a chance to catch up on my reading on planes and stuff, so I’ll get a chance to read this one. And then maybe we can circle back, maybe at the end of June in London, and we can talk a little bit more in depth about it.

    Schwartz: Uh huh. Sounds great.

    Shimel: Great. Hey, Marc Schwartz—iconoclast, CIO, or iconoclastic CIO as well as multiple award winning author, a real DevOps expert. His newest book, “War, Peace & IT,” you can find out more, get an excerpt from it on devopsy.kinsta.cloud, you can get it on Amazon or any number of good quality book sites.

    Hey, Marc, congratulations, and thanks for being our guest on DevOps Chat.

    Schwartz: Thank you very much.

    Shimel: Alright. Enjoy your day and we’ll be in touch.

    Schwartz: Thanks.

    Shimel: Alrighty. Bye bye. This is Alan Shimel for DevOps Chat and devopsy.kinsta.cloud. Have a great day.

    — Alan Shimel

  • DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    DevOps Chat: Enterprise DevOps Adoption, with Micro Focus’ Mark Levy

    Adopting DevOps means changes from how you build software to organizational processes and cultural behaviors. Large enterprises have even greater challenges to overcome, including supporting a large number of applications and addressing technical debt while also taking on new development initiatives like digital transformation.

    What can we learn from experienced DevOps practitioners?

    In this DevOps Chat we spoke with Mark Levy, director of strategy, software delivery at Micro Focus, covering seven keys to successful DevOps implementations at large enterprises.

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

    Transcript

    Mitch Ashley: Hi, everyone, this is Mitch Ashley with devopsy.kinsta.cloud, and you’re listening to another DevOps Chat podcast. Today, we’re tackling the topic of large enterprise adoption of DevOps—no small task, for sure.

    I’m very happy to welcome Mark Levy from Micro Focus. Mark, welcome.

    Mark Levy: Thank you, Mitch, and glad to be here.

    Ashley: Would you just tell us a little bit about yourself and what you do at Micro Focus?

    Levy: My name’s Mark Levy. I am a director and working in the product marketing organization, and I focus a lot on strategic marketing initiatives as an evangelist, a DevOps evangelist. I develop and write content and commentary about the DevOps market. I’ve had a 25-plus-year career, and like many people, I’ve had many positions. I started out as like a sysadmin and was a developer and managed dev teams.

    But, in 2007, I started to focus exclusively on application delivery. And so, that has been—this whole area of application delivery, software delivery is something that I’ve been really focused on for the last 10 or so years.

    Ashley: Well, tell us briefly, a little bit about Micro Focus. Not all of our listeners might know what you all do.

    Levy: So, Micro Focus has also gone through this major transformation over, I would wanna say, the five to eight years or so. You know, we’re a global enterprise software company. We were established in 1976, we have 14,000 employees and 40,000 enterprise customers, about 4,800 software engineers, and we really focus on large enterprises, helping them run and transform their business. We have sort of focused on four key areas of how do we support our customers through their digital transformation journey, and enterprise DevOps is one of them.

    Ashley: I imagine that our folks, listeners that are from large enterprises are gonna be particularly interested, and I’m sure there are learnings and information that will be useful to other folks as well.

    So, you talked about playing in the space with large enterprises. I imagine that’s probably some global international companies, maybe some that are both European or U.S.-based as well. How would you describe how you differentiate what you do as Micro Focus as compared to other folks? There’s a lot of companies, of course, working to try to help enterprises adopt DevOps.

    Levy: Yeah, of course. And that’s sort of what I’d like to do first maybe is just sort of set the stage, because I always look at this, especially in the enterprise IT world, it’s so interesting. You know, Gartner made this sort of—you know, their strategic assumptions. And they said something like, through 2021, at least 80% of the DevOps initiatives will fail.

    Ashley: I have not seen that, no. Interesting.

    Levy: I don’t know if you’ve heard that, but—yeah. So, it’s interesting. What does that tell me—tell us, I believe? One is, the business is already in the fight. The enterprise, the business side is already in this digital economy and fight. We see that on the streets.

    And the other thing is, you know, IT is sort of behind the curve. And the reality is that our customers, the IT customers, the IT organizations have this incredibly complex hybrid landscape, it spans mainframe, mobile, on-prem, off-prem, and while the principles—the main DevOps principles—are similar to what the unicorns, so to speak, are delivering, that it’s really a whole different challenge.

    Because what’s critical is that there’s this above the line mandate to drive new digital revenue, but at the same time, you know, optimize the enterprise. And, you know, I sort of—I like one of my colleagues, his reference. It’s like, redesigning a jet plane while you’re flying it, you know? And so, I think that’s how, you know, what’s critical with large enterprises is that they’re trying to transform themselves and at the same time run the business.

    Ashley: Yeah, I would almost describe for a large enterprise, it’s like trying to build or transform the entire fleet of planes while you’re building it.

    Levy: Yes! Exactly.

    Ashley: Talk a little bit about—I mean, we all, I think, can appreciate in every business, especially large enterprise, they’re saddled with technical debt; they, of course, are working on operational efficiencies; they have applications that they’re trying to support and maintain.

    How do they take on something like a DevOps initiative successfully, as you were pointing out earlier, so that it doesn’t just stop at one group and kind of fall off from there, they really wanna be able to transform their part of their business? How do you do that?

    Levy: Right. So, I think one of the key things that we focus on enabling our customers to build on what already works, okay? They have all these core investments, and how can they take their core investments and leverage the ROI that they’re already having today, but implement new technologies and DevOps practices and capabilities? And I think that’s critical. I mean, how do they implement and scale DevOps practices, for example? It’s very, very important, and it’s hard.

    And so, we look at it from the basis of, how can our solutions and our products help them really get from point A to B? What is their current state now? Which is what they really need to understand. And it’s amazing how many companies really don’t have a current understanding, detailed, of their current state.

    Ashley: Mm-hmm, or a common one. [Laughter]

    Levy: Or a common one, because, you know, it changes a lot, but how do they deliver value to the customer? You know, what are their value streams, and what are the processes and the flow of artifacts? And so, they need to understand their current state.

    And then, they need to do a number of things that I know the people that are helping the DevOps community, the DevOps community have been evangelizing for a while—I think critical, especially in large organizations and enterprises, you know, they need to first really create this culture of continuous improvement. I think that’s critical.

    Ashley: Okay.

    Levy: You know, they need to enable, motivate and empower the teams, and the leaders really need to get on board, right? Without the leaders, it just will not work.

    Ashley: Yeah, I can speak from personal experience—instituting a continuous improvement culture is no small task in and of itself.

    Levy: Right, and you know, the thing is, the leadership style must also change, right? I mean, command and control really doesn’t work, decisions—it’s about empowering your product teams to drive as much decision making as possible. And that sort of has gone contrary to, you know, the organizational structure of the large enterprises.

    Ashley: Mm-hmm.

    Levy: So, that, I think, you know, is one of the critical challenges that these companies are faced with. Edward Deming made a great quote, “A bad system will beat a good person every time,” right?

    Ashley: Mm-hmm.

    Levy: And when I think of a bad system, I think, in its largest sense, the system. And this is where I think Micro Focus can help quite a bit is, anyone wanting to change this culture really needs to define the actions and behaviors that they desire and then design sort of the work processes that are necessary to reinforce those behaviors.

    So, you know, systems, processes, tools, help with and enforce good culture. But you know, if you have a bad system, it’s not gonna work. So, I think, you know, these are areas that we can help on the cultural side. I come back to thinking about the idea that, you know, sort of the general friction between dev and ops teams, where ops teams are really, initially, only measured by mitigating risk, and dev teams are only measured by delivering change. You know, there’s the conflict that has to be resolved. That’s critical.

    Ashley: You’re talking about culture; the other thing that occurs to me is, there can also be inherent or built in incentives that are counter to the culture that you’re trying to create. That friction is a good example for one. But, you know, there may be past punishment for failures or, you know, emphasis on down time, so the answer is always minimize change or whatever it might be. You’ve gotta take those things head on.

    Levy: Exactly, yeah. And so, I think, you know, you ask sort of where people start. I think, you know, you need to start—and everyone, a lot of people talk about this, and it is true. You really need to start instituting this culture of change, because DevOps drives a lot of change. It’s a transformational journey in the enterprise.

    Ashley: When you said, the number one thing you said was, “Leverage what works.”

    Levy: Yes.

    Ashley: What do you look for? What kind of things are you trying to say, “That’s a practice you do well, and let’s keep that, or let’s build upon that”—what do you look for?

    Levy: Well, you know, I think about, there’s a lot of legacy systems, core investments that these large enterprises have had and invested lots of money and time into it. And take, for example, COBOL, okay? That language, I think people are not necessarily aware how invasive it is. There’s still about 250 billion lines of COBOL around, right?

    Ashley: Mm-hmm, mm-hmm.

    Levy: It drives 70%, they say, of all business transactions—still, in the world.

    Ashley: That’s amazing.

    Levy: It is amazing.

    Ashley: [Laughter]

    Levy: And so, you know, I’ll give you an example of sort of what we’ve done and we’re, you know, we are very good at managing and understanding those environments. We have, you know, that’s a big part of our business. So, we can, you know, lift—if we can lift and shift, you know, COBOL workloads off of, you know, sort of the more legacy platforms into, let’s say, AWS, you know, that’s a big win for our customers.

    As an example, we had one customer that basically had—it was a major global insurer, had about eight different IT environments with a back end COBOL app sitting on the mainframe and then front end and WebOps. And basically, each environment cost about $3 million a year. And, to request that environment, to provision that environment, took six weeks.

    Ashley: Mm-hmm, mm-hmm.

    Levy: And so, we built, through our solutions, we were able to lift and shift that workload to AWS and reduce the cost from 3 million to 120K and reduce the provisioning time from six weeks to two hours.

    Ashley: And I wanna mention, too, to our listeners, too, we just had a webinar in the last week talking about mainframe APIs and frameworks specifically to mainframe environments to make it a little bit easier to adopt WebOps. So, though it doesn’t get the kind of sex appeal that necessarily new technology does, it is a huge, huge issue for enterprises and how do you bring the mainframe environment with the rest of the cloud and everything else.

    Levy: Right, it’s—you know, back to the theory of constraints. I mean, in your value stream, if—you know, you can develop and you can be an agile team, but if it takes six weeks to provision, you know, your mainframe environment?

    Ashley: Where do you suggest people get started? Is it go pick a new, from scratch greenfield project, or pick something that’s, you know, reasonably mission critical so we’ll get the support?

    Levy: Yeah. Well, I think one is, I like, initially, to set up a lab, like taking a greenfield. You need a place to learn. A lot of these things aren’t easy, or they’re not, people are not, the teams are not used to. So, like, I love the idea of what a lot of the community’s doing with DevOps dojos and building sort of a team level, maybe CI/CD, have a place to experiment and take that.

    But then, you know, ultimately, in large enterprises, they’re gonna come up. They might get easy wins early, right, but the challenge is, once they scale, they’re gonna run into some of the more challenging times. And that’s where, back to what they have to really start doing is taking this broader, system level view of the enterprise.

    So, you know, if they understand how they’re delivering value to their customers—and in enterprise, there’s many ways to do that—then they need to understand and prioritize according to the business objectives. Let’s say one business objective might be, we need to recapture value. Maybe our IT budget isn’t really growing, but we need to drive for more innovation. So, we need to—our objective is to recapture that value and redeploy it into delivering value and innovation. And so, that would drive a lot of your decisions in where you optimize.

    Ashley: Speaking of budgets being flat or not growing, digital transformation is all the rage, that’s what many, many companies are taking on, not just in customer experience, but across the enterprise, bringing them into the digital world. How does that fit on top of this if you’re trying to introduce DevOps?

    Levy: I don’t see how they can really run their digital transformation without DevOps. I mean, software today—you know, I talk about this a lot where business innovation and software innovation are generally becoming one and the same, right?

    Ashley: Mm-hmm.

    Levy: And going quick, innovating faster with less risk is critical. And so, IT is, you know, it’s imperative to really deploy DevOps practices to support the digital transformation of the business. So, I think, you know, the IT organizations that implement DevOps, those people are the drivers.

    Ashley: Well, and it’s hard to imagine how you were gonna transform systems and applications you already have as well as ones you might leverage as SaaS services or create yourself without an environment to integrate those altogether due to continuous integration testing, etcetera, as well as be responsive to the business.

    Levy: We’ve seen enterprises, they will typically start out, right, with their team level implementation and they might do really well, and it might be a greenfield app. Maybe it’s a new growth app, which is great, and they may get some early wins, which is super, but it’s still not their core business.

    Ashley: Mm-hmm.

    Levy: And so, they have to, ultimately, really transform their core business in order to be competitive in the market.

    Ashley: Mark, what’s the one thing organizations should not do when they’re looking to adopt DevOps—don’t make this mistake?

    Levy: I think the idea that they can just automate their way out of it, I think, is something that could get them in trouble. Because, you know, really leaving out the whole cultural aspect of it, it really is—you know, it’s interesting, if you read Jeff Bezos’ letter to shareholders every year, he just provides some incredibly insightful, you know, insights on how Amazon runs. He talks about this accelerated decision making process that they run, and they make these decisions, really, based on only 70% of the information that they need, basically. Whereas, large enterprises wait until they typically have 90%.

    And so, they are able to make decisions earlier because of the agility that they’ve built into their system and their culture of change. And this allows them to not only, you know, get earlier into the market, but it allows them to—everyone, it allows them that if they make a mistake, they can recover from their mistakes faster, and the cost of making a mistake actually goes down.

    Ashley: Mm-hmm.

    Levy: But this whole idea of organizational agility and providing that—there’s more than just delivering value faster to the customer, because it’s never a straight line, right, to success. So, we make a lot of mistakes and wrong turns in our journey, and being able to identify that quickly and have the agility to correct that quickly is actually more of a differentiator than just delivering fast.

    Ashley: It’s certainly required for any kind of agility. It’s not just getting things and getting decisions made faster, but changing when things aren’t headed in the right direction—or change.

    Levy: Right, right. And so, this is where, you know, if people are looking at DevOps, they’re saying, “Okay, well, we’re just gonna automate the deployment pipeline and we’re done?” No, there’s no “done,” it’s about really, ultimately, improving as an organization, right, and having that continuous improvement, the Kaizen kind of mentality of the organization. And that, to me, is what is so transformative as a company.

    Ashley: Going back to what you said in the beginning about having a culture of continuous improvement.

    Levy: Yeah, absolutely. And that, it would be, you know, frankly, the most powerful thing leaders can do—is that change. Because it really just changes the whole business. The business, then, gets more confidence, which is critical, right? With all this change, sometimes they’re not confident to make business decisions, but if you can provide them the confidence to go out there and really be aggressive, you know, that’s—you’re gonna see, you know, a whole bunch of positive results on the revenue side, on the public side of the business that’s been driven from, traditionally, the back office IT organization.

    Ashley: Well, Mark, I’d like to thank you. I’d like go for another 30 minutes, [Laughter] but I’d like to thank you for the time on the podcast. You know, I walk away with several things from our conversation. The things you shared that I heard were leverage what works, define your current state, create a culture of continuous improvement, command and control doesn’t work—you’ve got to empower product teams. Start with a lab or a dojo, some learning environment. I think your premise of, you can’t do digital transformation without DevOps is pretty intriguing. And last but not least is organizational agility, being able to make decisions quicker, get out ahead of things without having to have 100% of the information, kinda the Amazon model.

    Well, and that should wrap things up. I’d like to thank Mark Levy from Micro Focus for joining us. This is Mitch Ashley with devopsy.kinsta.cloud, and you’ve listened to another DevOps Chat.

    — Mitchell Ashley

  • DevOps Chat: We Are Devo, With Walter Scott

    DevOps Chat: We Are Devo, With Walter Scott

    If you have massive amounts of data, Devo wants to help. The Madrid-based company specializes in the handling and processing of massive amounts of data.

    In this DevOps Chat we spoke with Devo CEO Walter Scott about the use cases for Devo in a data-crazy world. Walter is a seasoned CEO in the tech sector. He knows a problem when he sees it and he thinks Devo is the answer. Have a listen to why and check out Devo at devo.com.

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

    Transcript

    Alan Shimel: Hey everyone, this is Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Really happy to have a new company, a new friend, joining us on DevOps Chat today. I have Walter Scott, CEO of Devo. Walter, welcome to DevOps Chat.

    Walter Scott: Thanks, Alan.

    Shimel: So, Walter, you and I met recently in Iceland, of all places, at a Insight IGNITE event that really kinda focused on DevOps, cloud, cybersecurity, if you will, the topics, but it was my first exposure to Devo. I don’t know if our audience is familiar with Devo. Why don’t you–give us the foundation, man. “We are Devo.” What are you guys? What do you do?

    Scott: Well, Devo is a data analytics platform that’s the next gen of technology, that provides a data fabric to allow our customers to take all of the noise that exists in the machines and petabytes, and petabytes of data coming in, for them to really start getting signals so that they can start their automation or their AI or their machine learning process, to make their companies more efficient; to be able to have them act more quickly; as well as to be able to get the people who use our platform, to get them the time back that they spend in managing the underlying data platform and allowing them to add the value to drive IT, to drive that value back to the business.

    Shimel: Excellent. And, you know, Walter, one of the things that impressed me with Devo was this wasn’t your sorta typical Silicon Valley story—a couple of wiz kids come up with a PowerPoint business plan and get funded via VCs, pre-revenue, pre-product even. Devo—the underlying technology here, the company’s been around a while and it’s not a Silicon Valley company, right?

    Scott: That is correct.

    Shimel: Give us a little background on that.

    Scott: Well, you know, over my six stints of being a CEO, I’ve never really run an American-based company. There’s great IT being built all over the world. I’ve done them from Malta to Scotland, Germany to Armenia to now with us here in Madrid, is where the company started. And we had a not Silicon Valley startup, but it was five guys—or four guys and a girl or woman—and started off the product in a research key, to really build something special and change the market because the bank that they worked for had to completely change the way they do business.

    And over the course of three years in research and we finally launched a product in 2014 and have been three-figure type growth every single year, since the date of the company being founded, ’cause it’s such a large market. And it’s really accelerating because of what we’re seeing happening with businesses and trying to get ahead of everything from getting arbitrage out of supply chain to solving their security problems, just to start with basic log management and monitoring to consolidate tools and increase agility.

    Shimel: Sure. So, Walter, you were—as you alluded to, this is your sixth or seventh startup where you’ve come in as CEO and had some tremendous success. And, look, not everyone is a success, right? That’s the mantra in business, but you keep plugging. When we look at Devo—and you and I spoke a little bit about this in Iceland, but so much of what we see as, quote unquote, “AI” today is really machine learning. And so much of machine learning is based, really, on data, right? You’re only as good as your data. In order to find patterns, you have to have enough data to analyze it and make actionable kinda calls out of it.

    But this is not a new problem and there’ve been other solutions. What makes Devo’s solution—I don’t know if you use the term “next-gen” or “new-gen” or something like that, but what makes Devo’s solution different?

    Scott: Well, you know, this has been going around a long, long time and you’ve heard me say, in the absence of data, the machine can’t learn. And I go back, all the way back, to the Walmart days in the ’80s, when they built—I would argue … them as the first person to really take the competitive advantage, coming from their data warehouse, right? And —

    Shimel: I agree.

    Scott: —They actually had the line, they could tell your daughter’s pregnant before you could by looking at the data. Well, today, that’s become necessary, but, over the last 10 years, it’s really—what’s happened with the cloud is being able to get that data manageable. I don’t like the term “AI.” I like more “augmented intelligence” because we’re not at the place—or even narrow AI ’cause I think it can solve very specific business problems that people might have. We have one customer that needed to actually build some ML and machine learning to detect what a bot was, were hitting their site, because, when they launched a new product, the bots would come in and sell it all in the secondary market. They wanted that brand loyalty to go to the end users.

    Or we have another customer that has a bunch of IoT devices integrated into their sporting equipment, where they’re trying to figure out if somebody’s gonna get hurt and using machine learning to be able to define what is that case, in terms of repetitive hits, but they need that data over long scales. And just the data science is actually making that possible. It could be done in the past; the problem was it just wasn’t cost-efficient enough to do it.

    We have customers that are taking literally over a trillion events a day to try to—and building machine learning models to understand which customers may leave their environment, based upon dropped calls or poor support integration. And it’s not just having that one set of data; it’s about having hundreds of different sets of data to help prove those hypotheses, to get those more and more efficient. And the data scientists are spending 70% to 80% of their time getting their arms around the data. We take that problem away from them and allow them to have—to solve that other 80% now, they can put in training their models and getting data to make them more and more efficient.

    Shimel: Excellent. Great answer. Hey, you know, Walter, you and I, this is neither one of our first rodeos. And, when I look at your job, your mission over there, at Devo, one of the things that I guess it’s a double-edged sword ’cause it presents so many opportunities, but, at the same time, there’s an axiom in business—“Put all your wood behind one arrow,” right? There are so many use cases for what you can do here, right? There’s the cybersecurity case, right? Where, “Look, man, we need this data. We need to be logging everything. We need to find if we’re under attack, where the attack’s coming from, what’s happening?,” right? So there’s that. And one can spin up an entire company around just using this kind of technology in cyber.

    You alluded to a few other use cases, right? That had nothing to do with cybersecurity. Better business intelligence. Understanding your customers better. Understanding your product better. There’s only so many targets, though, that you can go after, right? Without a tremendous—you know, you wanna build an IBM kind of force or something or a Dell force, that’s a whole different story. So how do you—Walter, as the CEO, how do you prioritize? What are the best use cases for this technology? What are the right markets for us to pursue?

    Scott: Well, what you say no to is just as important as what you say yes to, in a business.

    Shimel: Yep.

    Scott: And, right now, we are very, very focused in the Americas, as well as in western Europe, right? So we’ve been able to say no to Asia for another year or two. Our value proposition is really about the biggest of the big—the telcos, the banks, the large retailers, people who’re looking at real scale that they’re trying to solve problems with. But the fact is, is where I see the market going over the next three years is more about consolidating the DevOps, the ITOps, the Network Ops, the SecOps. All of those are coming into one. And I’ve heard a couple of people start using the term “fusion center,” which is really helping them drive the business and stop pointing fingers and reducing that mean time to response.

    Well, every security product starts with the logs, right? And every IT monitoring product starts with the logs and the data. And the advantage of us being able to load in all of that relational data, which is about 20% of our data that’s in our systems, across our customer base, is things that is coming out of Xdata or data warehouses or relational or customer application type or weather data or threat hunting data that comes in, and being able to combine all of that. So, for us, it’s the larger customers or companies that have data at scales that we’d see in the global 1,000 and really looking at the people who understand that what Google, and Apple, and Facebook, and Netflix have done is taken a data-first approach to their business.

    And, when we look at customers that are forward seeing—that see forward into the market, they realize there are a whole new set of competitors and being able to ask what their real competitive advantage is in their business and the data that it takes for them to be able to do that, whether that’s a telco to figure out how to launch a 5G network because they have all the 4G, 3G and 2G data, whether it’s in their customer retention rates or net retention of “Can they get more dollars out of their customers each year?” to whether it be their manufacturing process and figuring out that arbitrage in the supply chain.

    So I think we are—because of the ease of use of our product, because it’s so easy to get data in, because we keep data in raw format. So you can have one set of data that’s very easy to get in and use it 100 times, not having to index it or reduce that data because it just makes it more efficient.

    But I see us, in the next couple of years, really focused on the security side of the equation. Looking at people who’re doing the transformation and the weight that it’s gonna take on their DevOps and CloudOps teams and being able to work closely with the network and the DevOps teams to be able to grow their business because the cost of becoming so great on having so many different tools, at different layers of your network, I say that the best and the brightest companies will take control of their own data, consolidate those tools so they have a better competitive advantage.

    Shimel: Good. Good. Good. Walter, I’m gonna throw a term at you and I want your opinion on it, “AIOps.” What do you—this is a term that we, here at devopsy.kinsta.cloud anyway, we see it rising with a bullet. And, like you—to me, there’s AIOps with a capital “A” and a capital “I” and it’s like Robby the Robot stuff that’s gonna make us live like The Jetsons, finally. And then there’s AI with a small “a” and a small “i,” like the real, functional, kinda down in the dirt–maybe it’s not as sexy, but it provides real change for us. AIOps is—man, everyone—what’s your story on AIOps? It reminds me of when cloud came out in 2005. What do you think?

    Scott: So let’s be very clear. AIOps is a term that’s been coined by Gartner. Out of the last 100 conversations I’ve had with CIOs, I’ve only heard it referenced once or twice. I think it’s more the vendors that are getting on it. And, when you look at it, log management is a big part of AIOps. You know, user behavior analytics is part of AIOps. The anomaly detection is part of AIOps, right? There’s seven or eight different components to that. I don’t think any vendor right now, in the world, really has defined themselves as an AIOps vendor. I think we’ve probably got three years, through help of M&A and deciding what that is, ’cause incident response or the service management is also there, so I think it’s gotta evolve.

    But, of the seven or eight different components, the monitoring, the dealing with events, the user behavior, the anomaly detection and the log management is there, which is where we focus. And I think the enterprise log management, I thought, five, six years ago, was solved, when we solved who all those vendors are, but now, with the complexity of the cloud, it isn’t solved at the scale customers need to do with it. We had solved router management; now, with SD-WAN, it’s a whole new market.

    Shimel: Yeah. You’re right. I mean, and it’s funny that things that–it’s kinda like the measles, right? We thought we cured measles and here we are back with measles. Walter, we’re both CEOs of companies and I don’t know how many people listening out there are CEOs—many of our listeners are kinda getting their fingernails dirty, practitioners as well as managers at large enterprise—what keeps you up at night about Devo? What do you worry most about, Walter?

    Scott: Well, I think part is we have to manage tens or hundreds of petabytes of data for our customers, right? And I think we have a very large team internally for security, to make sure that the data that we have is protected and we work very closely with Amazon and Google and Azure to make sure that we address that. And that’s something that you’re never gonna sleep well ’cause you have to be passionate about making sure that you protect your customers.

    We were on the phone literally an hour ago with a manufacturer that makes toys for children, and that was the question that’s keeping him up–he says, “I have 10-year-old boys and girls logging into my website. I have to protect that data, making sure in the things that we do with being able to obfuscate data at the row, in the column level, without having to duplicate it and our algorithms that are in there.”

    But my job, as a CEO, is to help people build careers. I’ve been very fortunate in my career and have had some very large exits in part of the business, but it’s making sure that the team around us continues to make sure that we handle all of the things, in dealing with our business and our main offices in Madrid. We also have a big office in Cambridge, Massachusetts, because I love the guys and women coming out of MIT, where we do a lot of hiring. But it’s mostly about the team and then making sure that we continue to have what I call a industry-abnormal or an anomaly in terms of net retention. And our goal is to help our customers continue to grow because it benefits us and wanting to make sure that we make it easier for them to be able to get more value because our mission is about making IT so that they can provide data to the business that is actionable.

    And my belief is is the CISO or the CIO that has control of that data, if they push it out to the business and say, “Hey, did you know that, on this particular case or when this happens, we’re losing customers or we’re gaining customers?” That data is 80% more likely to be leveraged than it is if the customer asks the business. So—

    Shimel: Nice.

    Scott:–I think it’s empowering the IT to accelerate value to the business and most of my nights are, well, we see this new customer is bringing in this type of a data, bringing in our data science teams to help think about use cases that we can drive more value from.

    Shimel: Excellent. So, Walter, as I mentioned to you before we started recording today, the good news and bad news about this audio format is it goes so darn quickly. And we blew past our time. So what we’ll do, though, is we’ll—secret’s out: you live down in Florida, too. We’re gonna need to get you down here and into our studio and let’s do a whole video on this. We’ll continue our conversation in a video format. But, for now, we’re gonna call a—have to pull the plug on this one. Walter Scott, CEO of Devo, thanks for being our guest today on DevOps Chat.

    Scott: Great, Alan. Thanks.

    Shimel: All right. Hey, this is Alan Shimel, devopsy.kinsta.cloud, and you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: OPA and the CNCF, With Torin Sandall

    DevOps Chat: OPA and the CNCF, With Torin Sandall

    The Open Policy Agent (OPA) was accepted for incubation by the Cloud Native Computing Foundation. In this DevOps Chat we spoke with one of the founders of the project, Torin Sandall, about OPA and why the CNCF is the right place for OPA. We also discuss the company he works for, Styra, which works with OPA.

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


    Transcript

    Alan Shimel: Hey, everyone. This is Alan Shimel, MediaOps, the people behind devopsy.kinsta.cloud, Container Journal, Security Boulevard and DevOps Chat, and you’re listening to another DevOps Chat.

    I’m really happy to have as a guest for this DevOps Chat, Torin Sandall, and Torin is actually one of the co-founders of the Open Policy Agent (OPA) open source project, which recently came under the guidance management of Cloud Native Computing.

    So, let’s welcome Torin. Torin, you there?

    Torin Sandall: Hey, Alan. Yeah, great to talk to you.

    Shimel: Great to have you here, and a pleasure to have you joining us on this podcast. Torin, let’s first start off with, maybe there are people out here who don’t know what OPA is—what Open Policy Agent is, right? There’s some great, if you go to—actually, if you go to CNCF.io, there’s a blog article all about it and I’ll put it in our show notes. But for those who are following along or listening to this in their car or what have you, talk to us—what’s Open Policy Agent?

    Sandall: Yeah, that’s a great question, and it’s a good way to get started.

    So, Open Policy Agent is a domain agnostic policy engine, okay? So, it’s general purpose, meaning that you can kind of take it and use it to enforce all kinds of policies and governance regimes across a wide range of technology.

    So, for example, if you want to say that, you know, all of your containers have to be sourced from an internal image registry, you can express that kind of a policy with OPA, or the Open Policy Agent. If you want to do something like say that certain users can only see certain pieces of data served by a micro service, you can also do that with the Open Policy Agent. And if you want to restrict who can SSH into a server or run a pseudo command on a server, you can also do that with the Open Policy Agent.

    So, the idea is that we give people this engine that allows them to unify policy control across various pieces of their stack.

    Shimel: Excellent. And you know what’s interesting? I was talking to someone the other day and we were talking about, you know, how does Kubernetes fit into this whole Cloud Native thing? Because Cloud Native and the CNCF is bigger than just Kubernetes. And they gave me a really good analogy. They said, “Think of it as like, you know, a fleet of warships or, you know, a U.S. Navy fleet and maybe Kubernetes is the aircraft carrier. But there’s more to the Navy than the aircraft carrier. There’s more to a fleet than an aircraft carrier. There’s battleships and cruisers and destroyers and subs and frigates and amphibious landing ships,” and you know, I’m not a Navy expert. [Laughter] But there’s all these different elements that make up the fleet—and it’s a huge fleet.

    And so, you know, when I look at OPA, you know, Open Policy Agent—and we’re gonna talk about joining Cloud Native Computing Foundation—it’s a necessary ship in the fleet, right? That really makes it easier and more practical to use a lot of the tools that are not only in the fleet, but a lot of the commercial tools that kind of exist on the periphery as well. Fair?

    Sandall: Absolutely, yeah. The CNCF is a collection of projects that provide a lot of value within the overall ecosystem, and there are a few things that kind of bind them together, and those are kind of high level principles. So, you know, they’re all open source, they are all, you know, they’re oriented around containers. They’re oriented around very dynamic systems that you need to manage at scale.

    And so, one of the interesting things about a lot of the projects within the CNCF is that they are kind of building blocks. You can think of them as libraries or building blocks for the overall system, right? And so, you know, they integrate together, you can plug them into other systems and so on. And so, that’s how we kind of look at OPA. That’s how we think about OPA, is as a building block or as a library for enabling rich, fine grain control across a variety of parts of your environment.

    Shimel: Absolutely.

    Sandall: And, yeah, and so, policy is particularly important when you start to talk about adoption of technology within large organizations, right? As Kubernetes has matured and enterprises have really started to run with it and deploy real production workloads on top of it, they’ve recognized the need for not just simple best practice kind of security measures, but much more sophisticated and rich and fine grained rules and constraints that need to be enforced in a system in order to keep everybody safe. And so, that’s where OPA fits into Kubernetes.

    Shimel: Yeah, absolutely. You know what? I realized, and I apologize, I really didn’t do a good job of letting you introduce yourself to our audience on top of [Cross talk].

    Sandall: [Laughter] That’s okay.

    Shimel: So, Torin, I apologize. In addition to you being one of the co-founders of the project, why don’t you share a little bit about what you do in your day job and the rest of your life?

    Sandall: For sure, yeah. So, I think what’s relevant here is that I’m the co-founder of the Open Policy Agent project. I’m also a software engineer at a startup called Styra. We’re the makers of the Open Policy Agent. We founded the project about three years ago—a little over three years ago, actually, and yeah, so we’re kind of like the stewards of the project today. That said, we’re starting to see a lot more people from the community kind of come in and start contributing to Open Policy Agent and related kind of projects in the ecosystem.

    So, that’s sort of what I do. My focus is kind of on Open Policy Agent, but I’m super interested in the overall Cloud Native ecosystem and security and policy and all that kinda stuff.

    Shimel: So, you know, and I should also mention—I did a terrible job laying this one out, Torin, I apologize. We should also mention that the big news coming out—I guess it was this week, or maybe late last week—was that OPA, Open Policy Agent, has now become or come under the auspices of Cloud Native Computing Foundation (CNCF).

    Sandall: That’s right, yeah. So, we actually, we joined the CNCF as a sandbox to your project last year, in 2018. OPA was added into the CNCF sandbox. So, the CNCF has multiple tiers, and right now there’s sandbox, incubation and graduated.

    And so, this year, basically, they do a review of projects, you know, every year, and they check in on how the projects are doing and how they’re growing and how their communities are evolving. And that’s just useful, right? To kind of maintain, kind of, you know, good hygiene within the ecosystem. But this time around, we felt that—everybody kinda felt that OPA was growing quite a bit and it kind of deserved to move up to the next level incubation within the CNCF.

    And so, the move from sandbox to incubation is really a reflection of the progress that we’ve made over the last year in terms of both production users as well as proof of concepts and integrations, and new external contributors joining the project.

    Shimel: Got it. And, you know, I will just mention that, you know, CNCF has really done an amazing job of shepherding these projects, from sandbox into incubation, and then from incubation into graduation. I forgot the number, if it was five or six projects they’ve graduated now.

    Sandall: Yeah, I think there’s about five graduated projects today. You know, Kubernetes is one of them, it’s kind of one of the flagship projects, and there are others. And so, yeah, so, they’re really doing a good job of curating a very important set of building blocks, like I said, that are gonna help organizations get to cloud native.

    Shimel: So, let me ask you a question—and I think this is something our audience would really enjoy. How did you, as a co-founder of the OPA project, right, what was your sort of motivation for, you know, bringing it under the CNCF?

    Sandall: So, yeah, that’s a great question. What we found was that after, you know, the project had been around for over a year, or rather over almost two years, I guess. And what we found with talking to users and potential users was that they wanted to see OPA as part of a kind of vendor neutral organization, right? So, Styra, the company that I work for, had kind of built OPA, and it’s been open source since day one, but people really like to see these kinds of projects, these kinds of core infrastructure components a little bit decoupled from, like say, any particular organization.

    Shimel: Mm-hmm.

    Sandall: And so—

    Shimel: Well, not decoupled from any particular organization. Decoupled from any one particular vendor.

    Sandall: One vendor—yeah, sorry. One vendor.

    Shimel: There’s not a single vendor.

    Sandall: Yes. And so, you know, we looked around and we looked at the CNCF and we really liked what they were doing and we figured that that was the right place for OPA to be.

    So, you know, the CNCF basically provides us with this kind of vendor-neutral home for the project, and it allows us to kinda create a rallying point around policy in the cloud native ecosystem. So, that was the main, high level motivation for joining CNCF.

    Shimel: Got it. And it makes perfect sense. I mean, I’ve gotta tell you, you know, I don’t know if you’re familiar, but recently, the CNCF launched—not the CNCF, excuse me—the Linux Foundation, right, which is kinda the parent of the CNCF, right?—

    Sandall: Right, yes. Yes.

    Shimel: —launched another foundation called the CD Foundation, Continuous Delivery.

    Sandall: Yes, yes.

    Shimel: And CloudBees, the folks at CloudBees and the Jenkins project was given under to the CD Foundation. Jenkins had Jenkins X, Netflix put in Spinnaker and Google put in—I forget its name now, with a T.

    Sandall: Tekton?

    Shimel: Tekton. They put, you know, put Tekton into the thing. And I had a good chance to interview some of the CloudBees folks with this, and I asked them the same kinda question I just asked you. You know, and it was a very similar answer, that not only do end users perhaps shy away from a single vendor supported project, but it’s very hard for a project to break out of that mold and get other vendors or talent at other vendors to contribute, because they think they’re doing it for the benefit of one of their competitors.

    So, by putting it under a neutral party like this, you know, not only is it more palatable to your end users and to the community as a whole, but it’s especially more attractive to that segment of the community that are made up of vendors. And whether you hate vendors and you think they’re all commercial slime who sold out to the man or not, the fact of the matter is, those are the people who have the resources to put into these projects and to move the needle and to keep that ball moving forward and push the rope up the hill and all of that. So, can’t live with ‘em, can’t live without ‘em, and this is a great kinda middle ground.

    Sandall: That’s a good point, and I think that, you know, what we’re starting to see are more and more security vendors getting interested in OPA or Open Policy Agent. I like to call it OPA. It’s hard to call it O-P-A when you’ve got that OPA word that you can use, but anyway—

    Shimel: Yeah, yeah, yeah. [Laughter]

    Sandall: [Laughter] But yeah, so, we’re seeing more and more security vendors get interested in OPA and, you know, that is gonna be instrumental in the long run to achieving the goal of unifying policy control across a number of different systems, right? There’s never gonna be one vendor that rules everything and there’s always gonna be an amalgamation of different technologies. And so, you know, the best that we can do, I think, is provide this building block that can be embedded all over the place and that has, like, the fundamental kind of groundwork that enables unification. So, very exciting times.

    Shimel: Absolutely. So, I’m gonna ask you now to put on your entrepreneur’s hat, right? As a co-founder of your company as well, and let’s look at it Torin from that point of view. How is this helping—and I’m not familiar with your company, so I’m gonna apologize in advance. Say the name for us, again?

    Sandall: Sorry, the name of the company is Styra.

    Shimel: How do you spell that?

    Sandall: S-T-Y-R-A.

    Shimel: Got it. So, how does this help Styra?

    Sandall: That’s a great question. So, yeah, when the founders—I’m not a founder of Styra, I’m an employee at Styra.

    Shimel: Oh, I’m sorry. Okay.

    Sandall: But anyway, when the founders of Styra started the company, one of the things that they observed was that, in order to unify enforcement of policies across a wide range of technology, there would need to be kind of like a language based approach applied to the problem domain.

    And so, that’s one of the things that the Open Policy Agent provides—it gives people this high level declarative language that they can use to codify policies. And so, that was kind of recognized as something that would be needed, and what you quickly kind of—the conclusion you quickly arrive to is that, this was in 2016, 2015, and even more so today, it’s true, but what you quickly arrive at is the realization that that kind of a technology needs to be open source, right? It’s unlikely that organizations are going to want to adopt a proprietary, closed source language. It’s just not going to happen.

    And so, right from the very beginning of the company, it was recognized that an important part of the technology was going to be open source. And so, that’s how the kind of project sort of got started.

    Shimel: Got it. Got it, got it, got it. You know, I don’t wanna put you on the spot, but a little Styra background—Styra’s venture backed or bootstrapped, or?

    Sandall: Yeah, we’re venture-backed, and we recently did a bit of a launch at the RSA Conference a few weeks ago.

    Shimel: Really?

    Sandall: And so, that was very exciting, yeah. And so, you know, you can think of Styra as a control plane for policies. So, OPA kind of acts as the data plane, right? It’s this thing that you can embed into applications, you can embed it into Kubernetes, you can put it all over the place. But, what you need is also the ability to kind of manage those OPAs that are running all over the place.

    And this is what we see within the OPA community—the people that are using OPA building it into their systems. Companies like Netflix that have built an internal security platform around OPA, what they’ve ended up doing is creating a centralized management plane for policy and for security.

    And so, that’s what we’re doing at Styra is, we’re helping people kind of think about distributed enforcement of policy and centralized management of policy.

    Shimel: Got it.

    Sandall: So, we’re focusing today on Kubernetes and you can check out the website, we’ve got a bunch of information on there, but yeah, that’s the high level.

    Shimel: Excellent stuff. As a matter of fact, just looking at the website, I didn’t realize this but Styra is Bill Mann’s company.

    Sandall: That’s correct, yeah, he’s the CEO.

    Shimel: So—just to show you how old I am. I’ve known Bill Mann a really, really long time, like, I remember the day he joined CA.

    Sandall: Bill knows a lot of folks, yeah. [Laughter]

    Shimel: Yeah, he gets around. Bill’s been around, and so have I.

    Sandall: Yeah.

    Shimel: I don’t know if that’s a good or a bad thing, you know? But hey, we’re still kickin’. So, tell Bill I said hello, he’ll get a chuckle out of it.

    Sandall: Yeah. I will do that, yeah. And we’ve got a great founding team. They are some of the folks that did Nicira, which is one of the very, you know, basically, the first SDN kind of company, right? They [Cross talk]—

    Shimel: Yep, I remember that one as well.

    Sandall: Yeah. So, we’ve got a deep background within the security and policy space, and we’re kinda taking that and really bringing it into the cloud native ecosystem.

    Shimel: Very cool. You know, I don’t wanna make this about Styra because we really wanted to concentrate on OPA and CNCF, but maybe we’ll still, maybe we’ll schedule something, a second one, and we’ll talk—we’ll dive more into Styra.

    Sandall: Yeah, that would be great.

    Shimel: You guys are gonna be at KubeCon in Madrid—or I mean, in Barcelona?

    Sandall: We are gonna be in KubeCon, yes, in Barcelona in May. There are going to be a bunch of talks about Open Policy Agent. There’s gonna be, I think there’s at least three or four sessions that are happening. There’s also a little thing called Cloud Native Rejects the weekend before. [Laughter] These are the talks—like, the BSides Talks, basically for—

    Shimel: Yes. Well, that’s how Security BSides started.

    Sandall: Yeah, exactly. And so, there’s gonna be a session there with OPA content in it. So, yeah, it’s gonna be a great event.

    Shimel: Excellent.

    Sandall: And, of course, we’re gonna have a Styra booth at the event, so.

    Shimel: So, we will have a, you know, Digital Anarchist is our video platform, and we’ll have a Digital Anarchist set there where we’ll be doing videos. So, be sure—we’ll talk offline, but we’ll get you guys in for a video. We’ll follow up more on that.

    Sandall: Perfect! Yeah, looking forward to it.

    Shimel: So, is there a timeline for graduation from incubation at CNCF, or that’s kinda open?

    Sandall: It’s open. So, you know, they do a yearly review of the project, and it’s kind of up to, you know, the community and CNCF and everybody to kind of decide when that’s right. And so—yeah, so right now, one of the main criteria for graduation is around external contribution. And so, you know, over the next year, we’ll see how external contribution around OPA evolves and if it’s in the right place, then we’ll go ahead with that.

    But we’re really happy right now just with the move to incubation because it brings more visibility to the project, it lends more credibility to the project—you know, in addition to all the people that are using it in production, having it more prominently represented within the CNCF is great. So, we’re really happy with where we are today.

    Shimel: Fantastic, man. Hey, Torin, I had promised you we’ll do this in 15 minutes, and that was 25 minutes ago.

    Sandall: [Laughter]

    Shimel: So, I apologize for running over, but I thought we had a good conversation here.

    Sandall: Yeah, yeah. Thanks a lot, Alan. Yeah, I appreciate the time to talk about OPA and Styra and I look forward to—

    Shimel: Oh, it was really my pleasure. I’d like to—we’ll continue this at maybe KubeCon in May. But before we sign off—so, Styra is Styra.com, S-T-Y-R-A.com. The OPA project, right, is—

    Sandall: Yep.

    Shimel: —OpenPolicyAgent.org?

    Sandall: That’s correct, yep.

    Shimel: And, of course, you can find more information on it at the CNCF.io site, right?—

    Sandall: Absolutely, yeah, and it’s on GitHub and we also have a blog if you go to blog.OpenPolicyAgent.org, you can find out more there. So, yeah, check it out, and—yeah.

    Shimel: [Cross talk] It’s all good. Hey, Torin Sandall, co-founder of the OPA, Open Policy Agent project, which is now being incubated by Cloud Native Computing Foundation, as well as an employee at Styra—for my friend Bill Mann.

    Sandall: [Laughter]

    Shimel: So, good to have you on there. Say hello to Bill for me. Best of luck with OPA.

    Sandall: Will do.

    Shimel: And look forward to seeing you in May at KubeCon.

    Sandall: Looking forward to it. Talk to you later. Bye.

    Shimel: Alright Torin, thanks. Hey, this is Alan Shimel for devopsy.kinsta.cloud, Container Journal and Security Boulevard. You’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: ChefConf Update with Chef’s Nell Shamrell-Harrington

    DevOps Chat: ChefConf Update with Chef’s Nell Shamrell-Harrington

    2019 is shaping up as a “coming home” year for Chef. After recently reaffirming its commitment to an open source strategy, the company is gearing up for the best ChefConf yet. ChefConf, scheduled for May 20-23, is coming home to Seattle and many of the Chef favorites including Adam Jacobs, John Willis and more will be speaking.

    I had a chance to catch up with Nell Shamrell-Harrington, principal software development engineer and community engineering lead at Chef, who gave us a great preview of the whole event as well as her own presentation, and shared what her most anticipated sessions and activities are.

    You can still register for ChefConf, as well as get more information at: chefconf.chef.io/

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

    Transcript

    Alan Shimel: Hello, everyone, this Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat.

    Today’s DevOps Chat is all about the upcoming Chef Conference, and I’m happy to be joined by Nell Shamrell-Harrington, Principal Engineer at Chef. Nell, welcome to DevOps Chat.

    Nell Shamrell-Harrington: Hello, Alan! Greetings from Seattle. It’s fantastic to be here.

    Shimel: Yes, it is. How’s the weather in Seattle?

    Shamrell-Harrington: Surprisingly sunny today, and it wasn’t raining when I came in, so pretty darn good for Seattle in April.

    Shimel: Absolutely. Well, look—in April, April showers. But, you know, the whole weather in Seattle thing is a bit of a fallacy. You know, they get—

    Shamrell-Harrington: What I tell people, when they ask me does it rain a lot, I said, “Yes, but it’s not, like, soaking rain. There’s a constant mist in the air that gets in to your bones and makes you cold.” So, you learn to deal with that, but yep, greetings from beautiful for today, at least, Seattle.

    Shimel: Good for—[Laughter] good for you. Alright, so now, the big news is, we are, what, about a month, maybe a month and a week, a month and 10 days out of ChefConf, right?

    Shamrell-Harrington: We are indeed. I need to write my keynote. [Laughter]

    Shimel: I would say, let’s get started, yeah—might be a good idea. And this year, after ChefConf having kinda wandered around for a few years to Chicago and Austin and I think Santa Clara I was at one and a bunch of other places, you guys are coming home to Seattle, right?

    Shamrell-Harrington: We are indeed, and we are very excited about this. We look forward to welcoming the entire Chef community to our home of Seattle.

    Shimel: Absolutely. And when we say coming home now, you know, I think it’s figuratively and literally and kinda philosophically.

    Shamrell-Harrington: Absolutely.

    Shimel: As ChefConf really represents a sort of coming home for Chef in a lot of ways, do you agree?

    Shamrell-Harrington: I agree. We made the recent announcement—which I know you covered on a previous episode—about 100 percent of our product code now being open source. And one of the reasons we did that was, Chef was created through the open source community. Chef—I mean, the open source community built every piece of the foundation that Chef stands on, so we are returning to those roots with open sourcing 100 percent of our product code and a lot of the discussion about that will be at ChefConf in our geographical home as well.

    Shimel: Yep. And, you know, I mean, the open source, reaffirmation of the open source commitment, I think, is one part of it. I think another part of it, though, Nell is—you know, look, I’ve run devopsy.kinsta.cloud now for five, six years, right? And when I first got into DevOps, you know, Chef was one of the blocks of granite, if you will, upon which the DevOps foundation or the DevOps world was kinda built.

    And over the years, you know, there’s been a lot of shiny toys that have come, as such happens in the tech space, right?

    Shamrell-Harrington: Of course.

    Shimel: And you sort of say, “Yeah, you know, that was—you know, Chef almost was old and what is it doing to stay current? Is it still relevant? And there’s Kubernetes” and all of these things. But to me, this ChefConf represents a bold, provocative, confident Chef coming, in their home court, kinda like the Hawks, right, coming out of the—

    Shamrell-Harrington: Very much so, or their home stadium, but yes.

    Shimel: – with the 12th man, and saying, “Hey, man, we’re still here, we’re still kicking, but we’re still innovating, we’re still true to our roots, and we’re still helping people with DevOps.” Fair?

    Shamrell-Harrington: Absolutely. I believe that is completely fair. We are walking this DevOps journey together, both the Chef community and Chef the company as well. And this is bringing us back into sync.

    Shimel: Cool. So, let’s dive in a little bit. You mentioned the open source commitment, and we have covered that before. Give us some—you know, and you’re gonna keynote, right?

    Shamrell-Harrington: I am, indeed. I’ll be keynoting, I’ll be first up on day two. So, make sure to be there on time.

    Shimel: Can we get a little preview without getting in trouble?

    Shamrell-Harrington: Absolutely, we can. So, I will be discussing developing software through a community. When I was starting to brainstorm this talk, I was worried that—you know, I’m a Principal Engineer. I’m very used to giving technical talks. I was worried people would respond with, “Why are you giving a cultural talk?” And I realized, open source community, it’s not cultural or technical, it’s both. And that’s really where the magic of working in open source Chef has come.

    We work on fantastic technologies, we work with fantastic technologies including Kubernetes, Terraform, and so many more, but we do it with amazing humans.

    Shimel: Yeah, absolutely. Now, Nell, you’re not allowed to mentioned your keynote, but give me what you’re looking forward to, the top three things at ChefConf this year that you might be looking forward to. And if you wanna do five, feel free.

    Shamrell-Harrington: Absolutely! Well, for ChefConf itself, I’m really looking forward to the Community Summit on Monday, May 20th. That’s when we get together, we hold a bunch of open spaces, we talk about what Chef is doing and where we as both a company and a community wanna go.

    So, there’ll be a lot of talking at the summit on Monday, and then on Thursday, we have our hack day. It’s not a competitive hackathon, it’s more people getting together in groups and building something together. So, after we talk on Monday, we’ll start building what we’ve discussed on Thursday, and I hope to see everyone there.

    Shimel: Great. So, that’s one.

    Shamrell-Harrington: Right.

    Shimel: What are some of the others?

    Shamrell-Harrington: As far as the sessions go, we have sessions from people from retail, government, banks, major cloud providers, and so much more. A few that I am particularly looking forward to are “A Habitat for Democracy.” That’s going to be by Chris Alfano of Code of America. They use Habitat to help them—they use Habitat for civic hacking, essentially. So, looking forward to hearing more from him.

    Another one is, “FIPS Doesn’t Have to Be a Four Letter Word” from Keith Walters of TapHere! FIPS is Federal Information Processing Standards. It is as boring as it sounds, but it is extraordinarily important for our government customers, especially those who work in particularly sensitive areas of the government.

    And then the third one, I mentioned how Chef, it doesn’t compete with things like Hashicorp, Terraform, or Kubernetes, it works with them. And one talk I’m particularly looking forward to is, “Terraform and Chef.” That’ll be by Seth Lippman and Andy Herm of Oracle.

    Shimel: Very cool! You know, I will say, FIPS may not be boring, but it is expensive. [Laughter]

    Shamrell-Harrington: Very.

    Shimel: In my previous life, we had to have our information assurance, as the U.S. Army calls cyber security, our information assurance solutions FIPS certified for the encryptions and stuff. And that was an ordeal, to say the least, so, I’m interested to—I’d love to listen in on that one.

    You know, you mentioned Terraform. There’s a lot of stuff coming out of the Linux Foundation recently now—

    Shamrell-Harrington: Absolutely.

    Shimel: – between Cloud Native and now this new CD Foundation that’s spun up out of Linux Foundation. It really is, you know, this whole move to Cloud Native is, in many ways, in my mind, anyway, Chef and some of the foundational work you guys did kinda laid the groundwork for the move to a Cloud Native world.

    Shamrell-Harrington: Very much. You know, the groundwork, the reason Chef was founded, the reason Cloud Native was founded is, we had this still radical idea that working with technology did not have to be as painful as it normally is.

    I remember I reached out to Gene Kim on Twitter after I read The Phoenix Project and I told him, “You know, it actually made me physically cry,” the first half at least, because it was so familiar. All that pain of dealing with both technical debt and cultural debt.

    And what we’ve said at Chef, what Linux Foundation is saying, what other Cloud Native foundations are saying is—there is a better way. It does not have to be this painful. And we’re working to make a world where it’s not as painful as it has been to run technology.

    Shimel: Amen. You know, I remember sitting with Gene Kim reading a manuscript of Phoenix Project, and you know, those characters in there are composites of real people.

    Shamrell-Harrington: Oh, yes.

    Shimel: And when you—you know, when you think back to who the real people are, I mean, it is dead on. I mean, truth is truth is truth.

    So, I’m assuming there are gonna be people in our audience who are absolutely attending ChefConf, but there are also people who have attended them in the past, but then there’s also gonna be a lot of people who have never attended a ChefConf listening in. And, you know, for those who haven’t—shame on you.

    Shamrell-Harrington: [Laughter]

    Shimel: [Laughter] But beyond that, you know, you’re missing a great time, because it’s not all sessions, ChefConf.

    Shamrell-Harrington: Very much.

    Shimel: ChefConf is very much a community, a bit of a love fest, if you will, around Chef, right? And there’s always some great social activities. Can you give us a preview, maybe?

    Shamrell-Harrington: Sure. Two of the ones I’m looking forward to, I believe it’s on Tuesday, we’ll be holding game night. We started doing those at ChefConf a few years ago, and I’ve always appreciated it. I have hearing loss, so, when I’m in a big, crowded, very loud party, I can’t have conversations with people, because I’m only getting every third or fourth word, depending on what frequency their voice is.

    But with game night, it’s quieter. People are more focused, there’s something to do. I’ve met coworkers—or people who became my coworkers a year later through game night. It’s a wonderful way to connect on a deeply personal level with other attendees and other employees of Chef.

    Shimel: And it’s fun.

    Shamrell-Harrington: It’s absolutely fun. I think we’re gonna have, something we’ve traditionally had a Chef game night has been a gamed called Artemis, which is—I’m gonna get in trouble for saying this, but it’s kind of like a Star Trek LARP without actually being Star Trek. [Laughter] But there’ll be board games as well, card games, Adam Jacob always runs a Dungeons & Dragons campaign. It’s gonna be a wonderful world of geeky fun.

    And then, on Wednesday, if kinda the traditional party is more what you enjoy, we’ll be holding the community celebration. And because we want to highlight the wonderful things Seattle has to offer, it will be catered by Tom Douglas. For all you foodies out there, you know that’s a very, very big name, both in Seattle cuisine and nationally and internationally.

    And we have two classic Seattle bands playing. The first is Mudhoney, and the second is Deep Sea Diver. They will be playing the celebration, and we are very much looking forward to hearing them and sharing that with our community.

    Shimel: So, providing a little translation in the background, right? If Tom Douglas is there, there’s a good chance there might be some killer salmon.

    Shamrell-Harrington: Absolutely.

    Shimel: He makes—I was actually privileged, he did—I forgot what event or gathering I was at. But they brought Tom in, and he showed us how to fillet a salmon.

    Shamrell-Harrington: Oh! What a wonderful experience!

    Shimel: Yeah, that was pretty cool. And then, of course, we went to one of his restaurants for dinner, and it wasn’t terrible. But beyond that, the Chef party—and that’s usually like the last night or the night before the last day kind of thing.

    Shamrell-Harrington: Yeah, it’s the night before the hack day.

    Shimel: Yep, and that’s always a great party, because by then, you know, the sessions are in, people have networked around a bit, have talked about a lot of the technology, and it’s a good time to have a good time, right?

    Shamrell-Harrington: It is, absolutely. Whenever I’m speaking at a conference, I always enjoy the conference after my talk much more than the conference before my talk.

    Shimel: Right. Well, because before, you’re all tensed, keyed up on doing that. You know, Nell, you mentioned Adam Jacob, and I’m sure some of the folks sitting out there are saying, “Well, I heard Adam’s not the CTO any more. What’s he doing there?”

    Again, I think it talks to the power of Chef. I think it talks about Chef reaffirming its roots and all of that. It’s that—yes, Adam is not the CTO any more. He’s out doing his Foundation thing. But he is going to be there, he is presenting, if I’m—

    Shamrell-Harrington: He is. He’s presenting on day two as well.

    Shimel: What other kinda—John Willis is speaking as well. John, I think, was, I wanna say, employee eight or nine at Chef back in the day.

    Shamrell-Harrington: Mm-hmm.

    Shimel: And he’s also speaking, as well as he will be there on behalf of Digital Anarchist, which is a video platform John and I partner on—

    Shamrell-Harrington: Oh, great!

    Shimel: – and we’ll be doing interviews. Yes, we’ll be doing interviews all through ChefConf, so look for the little video set, if you wanna say hello to John or check out some of the videos we’re shooting.

    What about training, though? Isn’t there training or something going on earlier?

    Shamrell-Harrington: It is, indeed. Monday, which is the day of the Community Summit, along with the Community Summit, we’re running several training sessions. So, if you wanna learn more about Chef, you wanna learn more about Chef and Kubernetes—all sorts of topics. If you wanna get hands on before the sessions begin so you get familiar with the technologies that people are going to be presenting, that’s a great way to do it.

    Shimel: Absolutely, absolutely. So, you know, Nell, interesting—look, you’re a perfect person to speak to the ChefConf crowd, right? Because it is a fairly engineering focused crowd, right?

    Shamrell-Harrington: It is. It’s historically been primarily practitioners, though that is starting to change. We’re getting what we call decision makers as well, but it is primarily an engineering crowd.

    Shimel: You know, someone could be a practitioner and a decision maker.

    Shamrell-Harrington: Absolutely! [Laughter] Absolutely. And they make the best decision makers.

    Shimel: I guess they call that diversity, but anyway [Laughter]—in a funny kind of way. Anyway, but there’s really something for everything at Chef there. What I’m trying to get at is, I don’t want people listening to this who are saying, “Well, I’m not geeky enough for that” or, “I’m not an engineer” or, “I’m not a developer,” right? If you’re at all interested in how software is getting done, how today’s winning teams are doing it—I mean, there’s something there for you at Chef.

    If I can ask you—and we didn’t talk about this beforehand, so I don’t mean to put you on the spot—give me what you think is one session that, frankly, you don’t have to be an engineer for, and you’ll still get a lot out of it.

    Shamrell-Harrington: The one I would recommend is, “Bridging the Great Divide: Using Chef as a Spark for DevOps.” That is going to be given by Brittany Woods of CARFAX, and I believe will illustrate not just their technical transformation but their cultural transformation, because the two of them go hand in hand.

    Shimel: Absolutely. I gotta tell you, to this day still, one of my favorite ChefConf presentations was the guy from, was it Alaska Air, or Air Alaska? I always mix those—

    Shamrell-Harrington: It’s Alaska Airlines, yeah. The keynote a few years ago?

    Shimel: Yes.

    Shamrell-Harrington: I remember that, the CTO of Alaska Airlines. That was one of the best ones I’ve ever seen.

    Shimel: It was. That was a really good one. Anything else we wanna highlight?

    Shamrell-Harrington: I would say, if you deal with technology at all, whether that’s as a developer or as an engineer or something else entirely, ChefConf is the place for you. We are obviously going to be highlighting Chef solutions for how to do technology better, but that’s not the only thing we’ll be doing. If you wanna meet a lot of other people who are having the same struggles as you, solving those struggles in new and different ways, please come to ChefConf.

    Shimel: Excellent, excellent. You know what we haven’t done, though, Nell? We never told anyone where to go to get the information.

    Shamrell-Harrington: Ah! Head on over to—let me check it real quick—ChefConf.chef.io. Or, if you Google ChefConf, you should get the correct ChefConf. If you see that it’s a conference for food chefs, that’s probably not the right one, [Laughter] but check out ChefConf. It’s in Seattle at the end of May, and we would love to see you there.

    Shimel: Absolutely. And there’s still—there’s still tickets, I mean, you—

    Shamrell-Harrington: There are absolutely still tickets.

    Shimel: Cool. Hey, Nell Shamrell-Harrington, thanks for being our guest on this episode of DevOps Chat. Continued success with Chef, and looking forward to a rock and rolling ChefConf.

    Shamrell-Harrington: Thank you so much, Alan. Great to be here, and looking forward to seeing everyone at ChefConf.

    Shimel: Fantastic. We’ll talk to you soon. This is Alan Shimel for devopsy.kinsta.cloud with this update on the upcoming ChefConf conference. You can get more information at, I guess it’s ChefConf.chef.io, or just Google ChefConf.

    Until then, or until next time, you’ve just listened to another DevOps Chat.

    — Alan Shimel

  • DevOps Chat: Digital Transformation with Exadel’s Jonathan Fries

    DevOps Chat: Digital Transformation with Exadel’s Jonathan Fries

    In this DevOps Chat, Jonathan Fries, VP of Engineering and Digital Transformation at Exadel, tells us about the new Innovation Lab by Exadel—a place for organizations to accelerate their transformation. We also talk about the state of IT in general from his perch at Exadel, a company with 20 years of empowering IT.

    You can find out more about the Innovation Lab at exadel.com/innovation-lab/.

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

    Transcript

    Alan Shimel: Hello, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. This episode of DevOps Chat features Jonathan Fries of Exadel. Jonathan, welcome!

    Jonathan Fries: Hi, Alan. It’s great to be here.

    Shimel: Hey, it’s great to have you here, Jonathan, and I wanna thank you. It’s always nice to have a new company coming up on our chats here, so it’s—you know, some fresh blood for the audience. I assume most of our audience is not familiar with Exadel, so why don’t we start with that, Jonathan? Tell us a little bit about Exadel.

    Fries: Sure. So, Exadel is a global software engineering services firm. So, we help our clients write software. We have—we’re a global company, so we have offices in Eastern Europe, Belarus, Lithuania, Poland being kinda the big ones where we have our offices in Europe. And, you know, we help clients in a variety of areas. Probably our big verticals are health care, finance, transportation, media and entertainment, and high tech. And, you know, we have some really good clients in those areas. Health care, McKesson is one that people have heard of. Finance, we work with Deloitte. In the high tech world, we have HP and Google as our clients.

    So, we’re doing offshore development for a lot of it. We have teams that are either all in Europe or usually a hybrid of some people here in the U.S. and some people in Europe. We’ve got about a thousand developers in Europe, so that’s where a lot of our work gets done. We’ve been around for 20 years, and so yeah, that’s a bit about Exadel.

    Shimel: Another overnight sensation, huh?

    Fries: Pardon?

    Shimel: I said another overnight sensation.

    Fries: [Laughter] Yeah, it’s been a gradual sort of buildup of working with clients and, you know, getting to work with a lot of interesting companies and them recommending us to others.

    The name of the company actually comes from a combination of excellent and delivery. I always think that that’s an interesting fact to bring up, and I think it’s an important part about kind of who we are and where we come from and how we got that list of clients. You know, we’re all about building really great products, software products for our customers, and that’s how we’ve grown the business.

    Shimel: Sure. So, and Jonathan, you know, kidding aside about overnight sensation, that’s the right way to build the business, right? You don’t just—I mean, yeah, everybody wants to be a unicorn, but unicorns are mythical, right? [Laughter]

    Fries: [Laughter]

    Shimel: [Cross talk] the world and all of that, so good for you guys. But you know what I didn’t mention is, what exactly—and just sharing with the audience, what’s your position with Exadel?

    Fries: My title is Vice President of Engineering and Digital Transformation. So, my background is in the software development world doing software development, leading teams, eventually sort of managing engagements and things like that, and also today heading up the digital transformation practice inside of Exadel.

    So, my background comes from the technology world and software development, and that’s why I’m proud of—I’m proud of our engineering capabilities and what we’re able to do for customers.

    Shimel: Good for you, good for you. So, Jonathan, you know, digital transformation is such a buzzword today, right?

    Fries: Yep.

    Shimel: We’ve all heard it, you know, and the one thing I’ve learned is that, for many organizations, you know, digital transformation is hard, right? I’ve heard so many people say, “Well, this wasn’t as easy as it was made out to be.” And I think one of the issues is, is that, if you can’t define something, how can you achieve something? Right?

    Fries: Yeah.

    Shimel: And so, it starts with, “Well, what exactly does digital transformation mean?” And so, I’ll throw it back at you—what does digital transformation mean to you?

    Fries: So, digital transformation for us is about helping our clients with the—you know, the doing and the engineering work of doing digital transformation. So, it’s about software development—you know, in particular it’s cloud development today—QA automation, and DevOps. I mean, those are really the big three areas of expertise within the company that we’ve really brought together under the digital transformation sort of heading as well as our agile methodology expertise, and so, bringing kind of those four things together. And they completely make sense together, because, you know, DevOps is really kind of the technology reflection of agile methodology and agile methodology is kind of the methodology reflection of the DevOps technology mindset. And QA automation is so tightly wound into DevOps and really the way that we’re delivering software and the way that our DevOps solutions work are very much married a lot today to cloud development.

    And so, we’re bringing all of those things together, which are all things that Exadel had lots of expertise in, but figuring out how to make sure that we were weaving those strands together, if you will, in a really sort of explicit way and building up some solutions for clients. Not just, “Hey, we’re really good at those things, and we have people who can be really good at those things for you,” but we can bring all of our best practices together and some technology solutions together.

    So, that’s what it is for us. It’s very much, you know, we’re a software development, software engineering firm, so we really—you know, we’re not sort of going after the cultural transformation part of that, or the, you know, the change management. I mean, we certainly have experience with those things, but for us, it’s really about the development side of it and our expertise in helping clients take on hard projects and succeed.

    Shimel: Absolutely, absolutely. Let’s talk a little bit about something new that Exadel recently delivered, and that’s the Innovation Lab. Talk to us—what exactly is the Innovation Lab?

    Fries: Yeah, the Innovation Lab is, it’s a new offering that we’re bringing to the market that combines some things that we already have into one thing. So, you know, we’ve all heard about the importance of innovation and even innovation labs. You know, some companies have them or are creating them. Exadel’s Innovation Lab is sort of more of a virtual innovation lab as opposed to, say, a physical place that we help someone create.

    So, we already have something called Appery, which is a cross-platform, low code development environment for creating cross-platform mobile apps as well as, like, a low code backend that runs behind that. So, that’s a way to build software very quickly to create real, working software.

    We already have a lot of expertise in agile development, as I mentioned before. And so, that’s also part of what we do. We have really great resources, all of those developers that we have, you know, in Europe and some here. And we have some packaged solutions that are a part of those practices.

    So, we’re bringing those all together to help our clients innovate. So, you know, what we wanna do is help our clients who are looking for a way to move faster, experiment, try something, get some features in front of customers or business stakeholders more quickly, and the Innovation Lab is our sort of packaged solution for doing that.

    So we can, we bring all of those things together—low code development, agile, on-demand resources when there might be something. Since a lot of what people what to experiment today are things like artificial intelligence and blockchain and how can we make those things work for us, so that’s—you know, often, we might have to bring in, you know, we might have to bring in an expert to help out with that as well.

    So, it’s really, it’s all of those things to help our customers and new customers innovate more quickly.

    Shimel: Got it. So, you know, and to me, when I look at it, Jonathan, you know, we talk about digital transformation, and what I said before about how, if you can’t define it, how can you be successful, and even once you define it, it’s an experiment in a lot of ways, right? It’s kinda that classic DevOps where you deliver, you learn, you get feedback loops, you iterate, you reiterate, and you keep reiterating.

    And an innovation lab is kinda the perfect place to kinda have that sort of learning that propels, that helps you define and then succeed in your digital transformation, right?

    Fries: Yep.

    Shimel: You know, you don’t wanna practice, I guess, on live TV or stuff like that. But you need—you need these labs to push the envelope and find out what works for you and what doesn’t work for you.

    Fries: Yeah. I very much view it, you know, as an extension of the product owner, you know, life cycle from scrum. You know, there’s the regular sort of software development life cycle within scrum where you’re doing your sprints and you’re delivering software.

    Shimel: Mm-hmm.

    Fries: But a big part of what the product owner should be doing is developing the product backlog which includes, you know, testable hypotheses. That’s kinda the way that the scrum community talks about it.

    And so, the Innovation Lab is a way for product owners to test some hypotheses that they might not be able to test, you know, if they already have a product. Like, you may not wanna do all the work to develop it and test the hypotheses over here, or that hypothesis over here. You may wanna use something like the Innovation Lab where we can use some of the tools at our disposal to create something that you can deliver and test out one of those—you know, test a hypothesis kind of on its own, if you will—but with working software. Which, you know, as we know is also a big part of agile and DevOps. You know, wireframes and requirements are great and they have a place, but they’re not the best way to show people what you’re doing or get feedback, and this really allows us to help clients do that and do it more quickly.

    Shimel: Got it. I agree 100 percent. Interesting—great idea. Moving off Innovation Lab, there’s other stuff going on at Exadel. You wanna share with our audience a little bit?

    Fries: Sure, yeah. We just launched the practice areas. As I mentioned, I’m the head of the Digital Transformation practice, and we also have a Digital Marketing Technology practice and a Products and Platforms practice that, much like digital transformation, the other two are also things that, you know, in places where we already have a fair amount of expertise and were kind of collecting all of that together in one place.

    So, for Digital Marketing Technology, we have some pretty significant clients for whom we’ve done work with Adobe Experience Manager to build global, localized, large scale websites. And since we had really done that several times, the Digital Marketing Technology practice is all about packaging that solution and delivering that to other clients for kind of building those large scale worldwide type of websites with Adobe.

    Products and Platforms is—you know, given that we’ve developed Appery, which really is, you know, it’s not just an application, it’s a whole platform for building other applications, and we’ve done that both for ourselves with Appery as well with several of our other clients like GHX where we’re creating a lot more than just an application, it’s this whole ecosystem. And so, that Products and Platforms practice sort of brings together the best of our knowledge base about developing those really sophisticated, large scale platforms.

    And Digital Transformation, of course, which is mine, is all about DevOps, cloud tech, QA automation, and agile. We have a solution that we’re putting together within the Digital Transformation practice that is a cross-cloud Kubernetes implementation that’s all done with Terraform and we’re actually getting ready to use that with the first customer now. We’ve kinda been just doing our internal dev on it, but we’ve shown it to some people and they’re pretty interested in that. The first customer will probably just use it on Azure, but it’s got some really sophisticated—you know, deploying Kubernetes with Terraform, autoscaling, a lot of really cool tech for containerized application development. So, I’m pretty excited about that.

    Shimel: So am I. I mean, it’s an exciting time to be alive in IT. I mean, from a developer point of view, from an ops point of view, there are so many options and so—you know, such power at your fingertips.

    Fries: Yeah.

    Shimel: It really is, you know, it’s a golden age to be into this kinda stuff.

    Fries: Yeah, I agree. I mean, I just—I think it’s an amazing time and, you know, I think there’s so much opportunity. There’s so much opportunity out there in what you can do and so forth and then how easy it is now to, you know, to bring computing solutions online for stuff, you know, and it’s what can be done.

    It’s awesome, and I know that, you know, it’s a lot of change and it can be hard on people sometimes, but I’m definitely an optimist and an “all ships will rise” type of guy, so, you know, I see all those opportunities out there and it’s like—you know, yeah, there’s an awful lot exciting going on.

    Shimel: Well, you know, Jonathan, I think in our business, either we can be optimists, or we can be cynics.

    Fries: Yeah.

    Shimel: I got into it yesterday, some guy, I don’t even remember his name, but he tweeted, “Oh, those DevOps people selling snake oil! There’s no such thing!” I think they reach a certain age where they just feel like there’s nothing new under the sun, and therefore, they’re just gonna bad mouth, right, whatever new comes along, and—hey man, you know, there’s a place for them on Earth, too, I guess.

    Fries: Yeah, and I mean, I think there’s always, I think, a real reason to be concerned about automation and the changes that that brings to not just our industry, but all of society. I mean, you can look around and see how much automation is impacting everything and, you know, as somebody with—you know, I have kids who are grade school aged kids, and it’s like, the world’s gonna look a lot different 20 years from now, so here’s what you need to spend your time thinking about and learning. Because, you know, if you really wanna do this kinda job, it’s not gonna be there 20 years from now.

    Shimel: And I have kids in high school and college and I’m telling them the same thing, man. It’s a crazy world. But you know something? To me, you know, we talk about being optimist, pessimist—Jonathan, the flip side of digital transformation is disruption.

    Fries: Yeah.

    Shimel: Right? And so, you get to the haves and the have nots. You have the empowered people who embrace transformation and are accelerating their business, and you have the laggards who don’t, and they may very well have to die off, right?

    Fries: Yeah.

    Shimel: I think that’s the choice that we—you know, that it’s nice to talk about this golden age, but that’s also the choice out there is, you can get with it or fall by the wayside. It’s compete or die. And, you know, that may be harsh to some, but that, I think, is the way it is.

    Fries: Yeah. It’s kind of been true for, you know, for a while, honestly. Industrialization automated some things, and like I said, I think, at the end of the day, the new businesses that will be created by digital transformation, the businesses that will be completely transformed by digital transformation will create, you know, even more opportunity, and as long as you are looking at it through the lens of those things, even though automation can be—you know, it can be scary.

    I mean, like I said, I came from—I was a developer and worked in IT and things like that, and you know, there was lots of things even 20 years ago, where it’s like, “Oh, these things are gonna change everything and jobs will go away” and it’s like—you know, that’s—

    Shimel: [Cross talk] Doesn’t happen, doesn’t happen. Anyway, Jonathan—

    Fries: No, it happens.

    Shimel: – when we started, I told you, the 15 minutes goes really quick, man. [Laughter]

    Fries: Yeah.

    Shimel: And we’re way over already. I apologize, but I didn’t wanna stop you, you were on a roll, and I thought it was a good conversation. So, but we’re gonna need to pull the plug on this episode of DevOps Chat. Jonathan Fries from Exadel, thanks for being our guest today.

    Fries: Absolutely, Alan. It was great. Thanks for having me.

    Shimel: Alright! This is Alan Shimel, devopsy.kinsta.cloud, and you just listened to another DevOps Chat.

    — Alan Shimel