devopsy.kinsta.cloud

Category: Podcasts

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

June 28, 2019
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

June 17, 2019
CloudBees’ Acquisition of Rollout: The CEOs’ View

As Mike Vizard reported yesterday, CloudBees, as part of its mission to build “the world’s first end-to-end automated software delivery system,” announced another acquisition: Rollout, a developer of a feature flag application that allows for simplified testing of new modules within an application.

Not to repeat the gist of Vizard’s article; you can read it for yourself. But this continues what has become something of an acquisition tear by CloudBees. The company has acquired CodeShip and Electric Cloud, among others, while becoming one of the founding members of the new Continuous Delivery Foundation (CDF), under the Linux Foundation and a sister foundation to the Cloud Native Computing Foundation (CNCF) and the Cloud Foundry Foundation. The CDF is now managing the Jenkins project, as well as Jenkins X, Spinnaker and Tekton.

CloudBees’ Mission

Make no mistake: These acquisitions, along with the CDF formation, represent a major change for CloudBees. The team there is clearly trying to separate from the pack of “end-to-end” DevOps contenders. CloudBees CEO Sacha Labourey is pushing hard to raise CloudBees above the noise and the rest of the market. The company announced a $62 million round of financing about a year ago.

You don’t have to be Warren Buffet to see that CloudBees sees an opportunity here. The company is driving toward achieving scale in product and revenue on the path to some sort of liquidity event (perhaps an IPO?) or market leading opportunity.

For now, though, back to the Rollout acquisition. I had the chance to sit down with Labourey and the CEO and founder of Rollout, Erez Rusovsky. We discussed what Rollout does, its history and how it will fit into the CloudBees product portfolio.

It is always great to interview a founder about his company being acquired. What a tremendous feeling of accomplishment to found and build a company, and have another entity value it so much that you are willing to sell it to them. This goes so far beyond validation.

Congrats to Erez and the whole Rollout team and, of course, congratulations to Sacha, KK and the rest of the CloudBees team. This seems like a perfect fit.

In the meantime, here is my conversation with Sacha and Erez on the acquisition and more. Enjoy!

— Alan Shimel

June 12, 2019
True Digital Adoption Empowers Humans

True Digital Adoption empowers humans to use use technology which is almost exclusively digital. What are the killer apps that you use all the time? OK, of those handful (for most of you) of apps, how well do you know them? What percentage of the feature set do you really use? Making better use of the apps we already own is a key factor in transformation.

Gartner calls this category Digital Adoption Solutions (DAS). According to Gartner, “They assist employees with complex business processes, tasks infrequently performed and change management activities.” One of the leaders in this emerging category is Walkme.

Walkme as a Digital Adoption Solution

I was introduced to Walkme at a recent Insight Ignite event in Iceland. I saw a presentation from Amir Farhi of Walkme. He showed us a demo of how Walkme overlaid on an organization’s Salesforce install made it really easy to use with features that you may not be familiar with. Instantly, digital adoption became real for me.

Salesforce is, of course, a hugely popular application and in many cases this is a poster child for why digital adoption in general and Walkme in particular is a killer app in and of itself. But Walkme doesn’t end with Salesforce. You can use Walkme on just about any app, both public and your own private apps. It is a game changer and the bigger your enterprise, the bigger the payoff in using Walkme for digital adoption.

I invited Amir to join me on a video for Digital Anarchist to discuss digital adoption and show us a demo of Walkme. I am happy to share this with you below. Have a look and listen. I think you will agree that Walkme is one of those rare solutions that is so elementally easy to appreciate, your reaction will be, “Why didn’t I think of this?”

Here is my conversation with Amir on digital adoption:

— Alan Shimel

June 12, 2019
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

June 7, 2019
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

May 17, 2019
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

May 13, 2019
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

May 1, 2019
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

April 26, 2019
DevOps Chat: Performance Testing with SmartBear’s Keshav Vasudevan

In this DevOps Chat we speak with Keshav Vasudevan, product manager for performance testing at SmartBear. Keshav talks about the move to “end-to-end DevOps,” the importance of shifting left with testing and the latest state-of-the-art in performance and load testing with SmartBear.

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

Transcript

Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud. You’re listening to another DevOps Chat. Joining me in this DevOps Chat is Keshav Vasudevan – and I’m sure I mispronounced that; we’ll let him correct it. Keshav is with SmartBear and he’s our guest in this DevOps Chat. Keshav, welcome.

Keshav Vasudevan: Hey, thanks, Alan. So happy to be here and, yeah, I will correct it – it’s actually Keshav Vasudevan, so that’s how you say my last name. And I’m – I currently work at the –

Shimel: Vasudevan, okay.

Vasudevan: Yeah. I work –

Shimel: I’m glad you _____ –

Vasudevan: Uh-huh?

Shimel: Well, give us your – okay, so – and we’ll call you Keshav for the rest of the podcast today. But, Keshav, you’re with SmartBear, but why don’t you give our audience a little background? What’s your own personal journey here?

Vasudevan: Oh, of course. I mean, personally, I’m coming from an engineering background. Yeah, I love all things code. I love building applications and, in my spare time, I just love building mobile apps and Web-based apps as just hobby projects, which is why it felt like a natural fit to be at SmartBear Software. I’m incredibly passionate about quality as a whole and I understand and know the importance of having consistent quality to ensure the best optimal end-user experience.

So, at SmartBear, currently, I’m the product manager for performance testing and specifically in the LoadNinja application. And I help communicate the value of shift-left testing in the Agile- and DevOps-based ecosystems that typically we’re seeing the world shift towards. And, of course, I’m responsible for the product management and execution of our innovative, new, revolutionary platform in the performance-testing space, essentially allowing people to do real browser-based load testing at scale, which is unprecedented so far.

Shimel: Very cool. So, Keshav, you’re right in the heart of it of what SmartBear’s about, but SmartBear is a company – you know, when we look at the DevOps space, the move is obviously towards “bigger is better.” We have all these companies who are trying to do end-to-end DevOps and complete-life-cycle DevOps. SmartBear is a company that, for as long as I’m familiar with them, have had multiple products and plays – you know, I’m not saying you’re end-to-end DevOps or that’s what you aspire to be at SmartBear, but SmartBear is definitely a company where you aren’t singular product, singularly product-focused on any one area. SmartBear – you know, there was a lot of testing products, but there was a lot of other products too.

And, recently – well, historically, each of those products almost had their own identity, as they should, but the SmartBear moniker was almost secondary to the individual products. And, recently, we’ve seen that change, right? Where SmartBear has made a broader effort to bring all of these disparate products into a cohesive type of vision of going to market under “SmartBear.” You wanna elaborate on that a little bit? Or, better yet, give our audience kind of the breadth of all the different solutions SmartBear can help with.

Vasudevan: You bring up a great point, Alan. So SmartBear’s been around for almost ten years now. And, since our inception in 2009, we’ve grown into a global company, which testers and developers and architects and designers have come to trust with their overall software-development needs. Our initial focus, when we first started, was around software collaboration and testing, but, eventually, of course, as the company grew and as we added more talented people to the company and also as we grew in user base, we realized that we could actually solve much more broader functional use cases.

And so, since our inception, we right now have 11 global offices. We are a big advocate of open-source platforms and tools, and so a combination of our open-source tools, which is SoapUI, which is one of the most popular API-based testing tools, and Swagger, which includes, of course, the Swagger UI, the Editor, the Codegen, and the commercial SwaggerHub, are all part of our ecosystem. And so, in total, we have over 6.5 million users and over 22,000 customers of our commercial platforms. And, since we’ve started, we have over 500 employees. So that is history of SmartBear and where we are in its current state, but you’re absolutely right. We have a breadth of different products, that each essentially cater to different aspects of the overall software development life cycle.

And so, if you look at the overall life cycle, we have tools that cater to solving and solving use cases and problems and seeing the design phase of the software journey, the actual development and testing and collaboration aspect, cross-functional and performance testing. We’d integrated a bunch of our partners in the deployment phase, with AWS, for example, or Kubernetes. And, finally, in the actual post-production and post-deployment, we actually have monitoring tools as well. So we essentially play in the entire software development life cycle, and we cater to different audiences and our tools overall cater to different use cases in those journeys.

Now we’ve gotten a lot of good feedback for each of these products, but we also recognize, at the end of the day, that, today’s day and age, Agile and DevOps is the way products – or software-development teams are moving towards. This is primarily, again, because software development has evolved in order to meet the growing demands of consumers. And consumers right now, today’s consumers of software applications, are looking two important things. The first is they want features, right? The switching cost to go from one application to the next is going lower and lower, so, if I, as a consumer, am not getting the best features on a regular basis or new updates or enhancements on a regular basis, I might get frustrated and I might just move to another vendor. And the second thing is we have started to expect a lot of good quality in all the things that we’re consuming because, again, as we’re digital consumers, we know that, every day, we spend over 11 hours in front of our computer and looking through different applications. So we have come to expect a certain standard of quality.

And all of this ideal of fast development and incorporating testing and quality into every aspect of this journey is achieved with the ideal of incorporating Agile and DevOps into your workflow. And so we know that, to go across all of these different functions in a seamless and automated fashion, you have to essentially integrate all of the different tools that we have that cater to all of these individual use cases, in a seamless fashion as well. And so – oh, one other thing that we pride ourselves on is we, from a product level, we have a seamless integration across all of these different verticals, right?

So, for example, we have the ability in the performance-testing space to essentially integrate with Jenkins, with LoadNinja, that essentially now allows you to automate your load testing with real browsers at scale, meaning with 10 virtual users or 10,000 users. You can be rest assured that is the most accurate representation of load. All of this can be integrated and automated using Jenkins with a simple plug-in. Right? And this also then integrates with other tools. For example, we have an integration with our design tool, which is SwaggerHub, with our API-testing tool, which is SoapUI. So then you can essentially easily design your API, architect it easily, design the API, make sure it solves the end-user use cases, and then push it to the tester and developer to actually test out each of these functionalities. So we wanna make sure that this process, this ideal of DevOps, is actually achieved in execution with the seamless integration.

Now one level higher is the actual story and the marketing and the branding around it. And we’re proud to say that SmartBear recently unveiled its new brand that gives our customers and prospects and users a more cohesive understanding of how each of these tools fit together, feel proud of the fact that they’re now part of the SmartBear ecosystem, and allow them to, essentially, seamlessly move from one tool to the next because of maintaining the branding and user experience across each of these tools. And that was a huge undertaking that we did and we just unveiled it last year at our user conference, Connect. And we’ve gotten lot of, lot of, lot of good feedback about our new brand, our logo, and everything else around that. So it’s a long–winded way of saying, “Yes, you’re absolutely right. And we’re making sure that that we are achieving that as well.”

Shimel: Absolutely. And you know what? I have one of the shirts with the new logo they sent me too, so thanks for that. But, you know, the interesting takeaway here – I hear from so many and I recently received an e-mail from a fellow in the field who said, “Where do you see – we need to be moving to platforms. We need platforms to build on. And how do you build a platform? And where do you see the need for a platform?” And then you look at, as you’ve just laid out here, SmartBear and you take these tools and individual solutions, point-solutions that you guys had put together over the years, and showing how integration among them, as well as integrating with best-of-breed kinda tools out there, like a Jenkins and some of – and we were blessed in DevOps to have a lot of open-source solutions as well, but integrating with a lot of these open-source. I mean, this is how you stitch together a platform. This is how you get “one plus one equals three.” Right?

Vasudevan: Yes, exactly. Absolutely.

Shimel: Yep. So, Keshav, we’ve waste – we didn’t waste but we’ve spoken an awful lot about kind of background on SmartBear. I really wanted to spend our time talking about what’s new and what’s going on with you and your team there, so why don’t we dig down and peel the onion back a couple layers on that? What do you have – imagine you may – you know, you alluded to it earlier but let’s dig in: what’s happening?

Vasudevan: Absolutely. So one of the things, as I mentioned in my introduction, as something which we as a company are really passionate about, is ensuring quality. Right? And, over the last 15 to 30 years, over the last – well, let’s say over the last 15 years, we as users – and when I say “users,” anyone – me, you, our friend; it’s essentially consumers of applications – have started to expect a certain level of quality. And this is how software development has evolved, in order to meet this demand.

And, as we have touched upon, this is why Agile has evolved, which is essentially moving fast, allowing developers and engineers to build features in a much more faster way and deploy them seamlessly so that the end users get them in the quickest way possible. Right? And we’re always listening to the end-user feedback and updating the platform. Then there’s DevOps, right? Which is, again, trying to follow the same ideal and essentially having a much more collaborative approach towards testing, operations, and development together.

Now let’s go dissect quality, the testing aspect of it. Right? So Agile, to allow for Agile- and DevOps-based testing, functional testing tools have done a great job of keeping up with the times. Right? For example, we have two tools like that, which is SoapUI and TestComplete. And they’ve done a phenomenal job in terms of allowing people to quickly come in and create their test scripts, make sure it all works, make sure to write the test cases really quickly because they have features to do that, and then, again, automate the entire process, using maybe a REST API or, of course, using an existing CI/CD tool.

Performance testing, though, which is a huge – which is a big business KPI in today’s day and age, right, is something that people are still, to this day, scared to do. We talk to product teams and engineering teams on a daily basis, who tell us how important they know performance testing is. For example, we know that, if consumers take more than – if it takes more then 3 seconds for a certain e-commerce page to load, for a customer, they’ll leave. They’ll just go to another platform. The switching costs are getting lower and lower and people are getting more impatient, so, if it’s gonna take a while to do a certain transaction, people will leave. And that is a huge business loss at scale for your company, for your platform, and as an organization as a whole.

So product and engineering teams, Agile teams, want to do performance testing. However, performance testing, to this day, has not evolved to keep up with the growing needs of Agile and DevOps-based workflows. To this day, it takes such a long time, for me as a performance tester, to create a test script. I have to essentially learn – and, if I was a developer or functional tester wanting to do performance testing, I have to forget about it. I have to hire a consultant because my learning curve is gonna be so steep. I have to allocate a lot of time in my day-to-day operation in order to create a simple test script. This is because, over the last 30 years of performance testing, the technological process has not evolved at all. To this day, if you’re creating a performance test script, you have to record all the transactions between the browser and the server. You’re doing this under the protocol level. That is typically how you actually create a performance test script.

Now, as you know, the responses and the requests between server and client will have certain dynamic characteristics, like session IDs, cookies, and so on. So, in order to play this back across 1 user or 10,000 users to do the performance testing, you will have to do this programming and dynamic correlation. This process takes anywhere between several hours to a few days to even become successful, for the most basic transactions. Now imagine doing this for the complex applications that we have today, some of the AJAX applications which are very client-rich, in terms of actions and allowing users to do multiple things. The effort that is involved to do this multiplies threefold. Right?

And so this is why performance testing is still, to this day, seen as something which no one wants to touch. They’ll hire a consultant; they’ll have a centralized function to do this. Then there’s, of course, the actual process of emulating and creating the load itself because, to this day, we still use emulators to generate the load, which is not necessarily representative of the end-user experience.

So this is something we saw over the last one year and we decided to do something about it, which is what – you know, our engineers came together. We said, “We are passionate about this. We face this issue ourselves. Let’s do something about it.” And so, essentially, we productized a new approach to doing load testing, essentially allowing users or testers or developers or functional testers – anyone who’s passionate about performance testing, anyone who’s behind an application, be it a marketer, a product manager, a functional tester, or a performance tester – to essentially come in, record, and instantly play back the transactions that they record in the test script, without doing any programming or dynamic correlation whatsoever. Right?

And, from here, of course, you can – and take the script that you have and spin up tens of thousands of real browsers to go ahead and do the load test, based on these transactions. Right? This is a – I don’t use the word lightly here, but a revolutionary approach to actually doing performance testing because this is unprecedented, to essentially create browser-based test scripts without doing any sort of protocol-based recording, which allows you then to create test scripts out of the box. And then simulate tens of thousands of real browsers to run these scripts on them. So, as a user, as a tester, you’re, one, going to save over 50 to 70 percent of your time, doing the actual load testing, because the scripting process has become so much more easier. And you’re gonna get results that are coming straight from the browser, so you can be rest assured that this is the most accurate and realistic representation of the performances that your application will be showing for end users. And this is what LoadNinja is, as a product.

And, over the last five months, since we launched in October, end of October, during our user conference, we’ve seen tremendous traction in the market. We’ve seen so many customers come to us, sign up for annuals and partner with us, to essentially allow them to do load testing. And it’s just phenomenal, as a product manager, and it’s like seeing the vision come to fruition and actually seeing the people who are behind products – product managers, functional testers, all of them – coming and saying, “Hey, we can now do performance testing by ourselves, without necessarily having to get a certification with an expensive tool. Without having to spend so much more money and dollars trying to get a consultant.” They can do this all by themselves and that’s the most gratifying thing I ever heard. So, yeah. So there’s a lot happening, but the LoadNinja’s primarily something that we’re super proud of, as a company. It was built in house by us. The revolutionary technology to do this it’s something which performance testing has never seen to this day.

Shimel: You know, listening to you, all I can think of is back to my own days as a entrepreneur and developing security solutions, and we’d have to go get performance testing done. We were selling to DOD – it was large, large networks – and this is pre-DevOps, obviously, and pre-automation and pre-continuous. And, my god, the budget for the performance testing was bigger than the budget for the development team. It was nuts. I mean, it was – so, when I hear now about how this stuff is being done in the cloud and “automated” and “scalable” and the price points, it’s just crazy.

Vasudevan: It is. It is. We’ve come a long way. And, to this day, there’s still – performance testing is seen as a monolithic and centralized function, right? And so, to this day, what you saw years ago, many of the factors are still there. So, yeah. So you’re absolutely right and it’s good to see the cloud coming in, but as a performance-testing industry and tool vendors, we can do a lot more to push the boundaries and keep up with the growing demands of engineering and quality as a whole.

Shimel: Yep. Got it. Got it. You know, Keshav, I told you when we started things get out of control. We were supposed to go 15; we’re at 20 minutes.

Vasudevan: [Chuckles]

Shimel: We’ll have to continue our SmartBear discussion on another DevOps Chat, at another date. We’ll have you back on soon. But why don’t we put an end for it right here? But, before we do, people listening, they like what they heard; they’re interested. Where can they go get more information?

Vasudevan: Oh, absolutely. So the best place to go is loadninja.com, so L-O-A-D-N-I-N-J-A-dot-com. And you should have all the required information to become successful and get started. One of the things we pride ourselves, as a product and engineering team, is our turnaround for new features and enhancements. We deploy almost every week and, again, using the – many of the learnings, we learned from your website, Alan, in the DevOps world, to essentially continuously integrate and deploy every now and then, every week, in order to get the features and enhancements that users require. So go to loadninja.com; you’ll have all the required information to become successful.

Shimel: Fantastic. Thank you very much for being a guest on this DevOps Chat. And I am serious – we’ll have to have you back on here – but, for now, I think we’re gonna pull the plug on this episode. Thanks, everyone, for listening. This is Alan Shimel for devopsy.kinsta.cloud, Security Boulevard, Container Journal, Digital Anarchist. You’ve just listened to another DevOps Chat. Have a great day, everyone.

— Alan Shimel

April 19, 2019