devopsy.kinsta.cloud

Tag: devops chat

  • DevOps Chat: ITIL 4 and Achieving High Velocity IT

    DevOps Chat: ITIL 4 and Achieving High Velocity IT

    In this DevOps Chat, Mark Smalley of Smalley.IT, and Lead Editor with AXELOS of the ITIL 4 High Velocity IT joins ASG CEO Mitch Ashley to discuss his work creating this new contribution to ITIL 4. Mark shares the 5 value investments important for organizations seeking to operate at high velocity and some of the insights gained from himself and others covered in this ITIL 4 module.

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

    Transcript

    Mitch Ashley: Well,  I have the pleasure today of being joined by Mark Smalley. Mark is Lead Editor of High Velocity IT, part of the ITIL 4 initiative. Mark, welcome. He’s also with Smalley.IT, I believe a one-person firm. Welcome, Mark. Would you please introduce yourself, tell us a little bit about you and the kinda work that you do?

    Mark Smalley: Sure, Mitch—thank you, thank you. Yeah, Smalley.IT, I’ve been on my own for about eight years now; previously, around 30 years at Capgemini and other managed application service providers. So, very much on the application side, very much on the service provision side. That’s really my background. The personal background—born in London, but have lived in the Netherlands, just outside Amsterdam, for about 45 years now, which is not a bad place to be.

    Ashley: No, not bad at all.

    Smalley: One of the recent—yeah, one of the recent initiatives I was involved with was the AXELOS ITIL 4 update, responsible for the emergence, I say deliberately the emergence of the high velocity IT module, because it was quite an interesting process, pulling in knowledge from various areas in IT service management, but also agile DevOps and out of the IT space completely. For instance, some people may have come across The Toyota Way, the management book about the Toyota manufacturing process. Professor Jeff Liker at Michigan University, he kindly contributed a bit to the book about the Toyota Kata, which is about an improvement method based on scientific thinking. So, drew in people from various fields to try and get this thing off the ground.

    Ashley: That’s gotta make it really fun and engaging, too. Why don’t we start out with what do we mean by it? What’s a good definition of high velocity IT? How would you give kind of a working definition of that?

    Smalley: I’d first qualify it by saying it’s not actually high velocity IT, but it’s more about higher velocity IT, because high would imply that there’s low and you say, you know, “High is good, low is bad”—well, that’s not the case. We’re on a gradient, on a spectrum from lower to higher velocity. We’re looking at the kind of organizations that you’d say would be more digitally enabled than most.

    So, the kind of organizations that use technology to do things significantly differently or even do significantly different things because technology enables them to do that. And that requires a different way of thinking, a different way of working than many people are used to. So, the book’s about different ways of thinking, different ways of working, and primarily the people in the IT service management space who are now confronted with this digital stuff and how do we deal with that? And trying to get them—it’s sort of a guided tour through the kind of things that you come across in these more highly digitally enabled organizations to encourage them to unlearn the old ways of working that aren’t effective any more and integrate new ways of working, new approaches in how they do stuff.

    Ashley: I think one of the really important and kind of fascinating parts of your work on this, Mark, is it’s not just about the bubble of IT or the bubble of my part of, my role in IT, it’s that high velocity for the whole organization and how you all work together. And I know it really—there are many places to start, but clearly, product management, there’s some outcome that we’re doing all of this work for, some product or service or offering that we have, and that’s a great place to really engage in kind of a systems thinking about this.

    Smalley: Yeah, very much so. It’s taking the end to end perspective. We’ve defined five objectives to give us a bit of guidance in this space, talking firstly about valuable investments—are you doing the right thing in the first place? Are you automating the right kind of business processes? Are you building digital products and services that are appealing to the marketplace? Are you doing the right thing? Fast development—are you doing it quickly? Resilient operations—once it’s up and running, is it resilient? And deliberately using the word resilient rather than reliable, because the kind of systems we’re dealing with are often complex and therefore unpredictable in their nature. They will fail.

    Ashley: Mm-hmm.

    Smalley: You know, these are fail-safe systems, these are systems that should be safe to fail, so it’s about the resilience—how quickly can you get the systems back up and running? Then the fourth objective is co-created value. Then again, you have that broader chain; that’s when IT starts engaging again, with the user community, in that intricate and even intimate dance that they do together that’s, you know, to help the users derive value from the investment. And finally, the fifth overarching or underlying objective is all of the above—assured conformance, it should be able to assure conformance to governance risk and compliance requirements, whatever they are in your kind of organization.

    So, it certainly is, what you said, the big picture, end to end.

    Ashley: Mm-hmm, very much makes sense. You know, it’s interesting—tell me if this jives with what you’ve experienced. Highly reliability, the best way to do it is don’t change anything, right? Make it very stable. But we live in a world where business needs to execute quickly, but also dynamically to react to changing market conditions—you know, pandemic being a great example of that.

    Smalley: Yeah, yeah, yeah.

    Ashley: A tragic one, but very much one that’s outside of our control—but also, you know, offensive strategies to go after markets and that, and the degree that the whole chain, the whole kind of supply chain of the organization working together can effectively do that quickly and reliably, but also resiliently, because you want to be able to experiment and try things. And maybe you need to fail to find the right answer for product mix or whatever.

    So, I’m sorry, I don’t wanna go on too long, but it seems like that’s an underlying driver behind all of why you took this approach, at least in part.

    Smalley: Yeah. Well, certainly, if you look at the dominant thinking behind most of the guidance there’s something behind it. There’s that concept of co-creation, realizing that you don’t do stuff and chuck it over the wall, you have to engage with other stakeholders—one of the things.

    The other main thing is dealing with, working in complex environments. Again, using that word complexity in the sense of complex adaptive systems, organizational systems where you simply can’t predict what’s gonna happen and where you, because of the volatility, the unpredictability of stuff, you can say that’s bad but from a research and development perspective, you want to be able to, you know, 10 initiatives will fail, but it’s that 10th one that’s gonna make you millions. You’re gonna benefit from that unpredictability.

    So, it’s really, it’s from the start, through the whole life cycle that you’re dealing with the—with the unpredictability which, for many people in IT service management, is a bit disconcerting, because if you go back—go way back, and you look at where people came from, IT service management people were very much concerned with the stability of systems and putting a wall around them with the best of intentions, with the belief system safe is good, whereas the developers had a different perspective—fast is good. So, you’ve got this fast versus safe. And seemingly, irresolvable, that conflict.

    But if you look at it creatively—and this is something that we’ve got a lot to credit the DevOps community for, and we reference extensively stuff that’s gone on in the DevOps world in the High Velocity IT book. The idea that if you—and it goes back to lean as well, lean in particular, agile a little bit—working with small batches of work, if you do work in small batches and more frequently, then you reduce the risk, ________ smaller changes and less risk in bigger changes. And the interesting thing comes along now—if you do changes more frequently, instead of saving them up for each, you know, masses of changes each quarter, no, do them every day, then you develop your capability to change effectively.

    So, paradoxically, you’ve turned it around completely. The more often you change—small changes—the better your change capability and therefore the more confident you can be that the changes will go through pretty safely.

    Ashley: Mm-hmm.

    Smalley: And it’s interesting, the groups that have to interact together, like, if you’ve got a DevOps group or a classic IT service management group, they identify with their own belief system, and often, the belief system is, you know, safe is fast—sorry, safe is good as opposed to fast is good. And how do you—you know, you’ve got to get these people together and talk about this stuff to resolve the apparent conflict. But it’s great stuff trying to build bridges between these communities.

    Ashley: Yeah, I’m totally with you and thinking of the sort of lean mindset and agile and iterative, which is very much where software product and organizations have moved to or are moving there. What are the—how do you deal with some of the legacy silos and sort of that self-protection of don’t change things or don’t, you know, let’s focus on keeping things stable or whatever the mantra of those individual groups are? How can this book, for example, this module help people start to expand their thinking around those issues?

    Smalley: Well, firstly, if you look at organizations, they will vary in velocity across the various divisions and departments. So, firstly, you’ve got to take a look at which part of the organization are we looking at? What is the appropriate velocity in the business there? What kind of cadence applies to their work? Interesting looking at the pharma industry that’s traditionally been highly regulated with very long periods in which they work. There’s no point speeding things up if you have to wait years before you move to the next stage. It’s like doing the Olympic games—you don’t want the stadium there earlier; there’s no point. So, it’s got to be very much aligned with the business velocity.

    So, look at the specific parts of the business and, depending on the kind of speed—and possibly, you’re dealing with legacy systems that don’t need to go that much quicker. And the advice we like to give in the guidance is, the first couple of statements, the guidance is not complete, and the guidance is not intended to be prescriptive. We don’t pretend to be able to dictate, proscribe how people should act. Rather, we’re trying to encourage them to take a look at the 9 concepts and models that we’ve adopted, the 25 techniques to see which techniques do you think would apply to you. So, be selective, pick and mix, take a few things out, experiment with them, see if it works in your environment.

    Because this is going back to lean, you mentioned lean, going back to the lean movement, you’ll probably know many of our listeners, audience will know that the Toyota production system was the precursor to the lean movement. And one of the grand figures in the TPS Toyota Production System, was Taiichi Ohno, who came up with some wonderful sayings, one of which is, “You should think for yourself and face your own difficulties. Don’t try to borrow wisdom.” So, in other words, how another organization has done something, that’s not gonna work for you. You have a different kind of organization, so you really do have to dig deep and look at the specifics of your situation and pick the various parts that you think apply to you and just experiment and see whether they work. So, it’s—

    Ashley: Really more of an adaptive approach versus prescriptive, right? It has to be done a certain way because one organization succeeded at it that way.

    Smalley: Yeah, no, and of course, it’s very tempting, but people are looking for the quick fix. There’s a fabulous cartoon, if anybody wants to look up a great cartoon, if you look up “Simple but Wrong, Complex but Right” it comes up with a great cartoon and you see people following—there’s a sign pointing in two directions of people, the masses are following the sign “simple but wrong,” because they’re looking for a quick fix.

    Ashley: Mm-hmm.

    Smalley: And what better than looking at how another organization’s done stuff and say, “You know, let’s do that.” It’s not a good idea, usually. [Laughter] So, you do have to be very, very critical, very selective.

    Ashley: Well, these are systemic changes, they’re not quick fixes or just change this one thing of how you’re working and suddenly you’ll get different results. And one of those is, we think about specialties or specialization of what we do, but we’re also now thinking, it’s specialty roles, but it’s also how those things work across the life cycle development operations, product teams. So, individuals and teams’ abilities to work cross functionally is a much higher order skill than maybe we valued in the past.

    Smalley: Yeah, look at the—I think we can kind of credit the DevOps community for something, but look at the agile community, how the concept of multi-functional, cross-functional product teams have emerged where you’ve got business analyst disciplines, development disciplines, testing disciplines all working together.

    It’s interesting to think about the definition of done that they often apply as a concept that you’ll come across in agile and scrum, you know, “When are we done?” It often, in the scrum world, it ends with a potentially deployable increment of software, potentially deployable. The key word is potentially—it hasn’t been deployed yet. So, it’s just asking for an extension of that domain of the team to not stop when it’s deployable but actually deploy it, so start involving the DevOps kind of competencies as well. Then you could extend it further to the service area, because product owners should be aware that the kind of product that they’re building, that needs to be accessed by people, and service is the vehicle that gives users access to your product. You built a great software product, but it’s only through the vehicle of service that people get to it.

    And is the product owner,  is the product team looking as much at service as they should be? And I think that’s often not the case, and I’d certainly like to, in the role of bridge builder, like to encourage product teams to take a closer look at service and think about the kind of characteristics the service experience as well that they expect their users to have. So, you can see a service substrate going through all of the life cycle, really, alongside the software and infrastructure artifact.

    Ashley: I’m curious, you mentioned design earlier and maybe this is what you’re referring to. I’m curious if design thinking or the design approach is something that also influenced your work on this module, the idea that you’re really, the outcome isn’t the car, the outcome is the experience that the customer, the user of that vehicle has and expects, you know, from whatever the product is that you’re creating. Did that influence this work, too?

    Smalley: Yeah, two things, there—design thinking, we’ve referenced more at the start of the process, thinking about the kind of specifications requirements that people have. But towards the end, thinking about the service experience, and you’ll be familiar with the concept of service level agreements, which are often unfortunately formulated. We talk in terms of availability and performance and security and stuff like that—all very technical.

    But how do the users feel about this? We’re slowly extending that domain service level agreement to include experience level agreements, looking at outcome and how people feel about their engagement with either their technology or the people behind the technology. So, again, that’s that human co-creational dimension that you see in high velocity IT, alongside the technology.

    Ashley: Mm-hmm. Yeah, the SRE world, I don’t know if we’ve talked about that, but it has this idea of service level objectives, which is a little less formal and restrictive as what we think of contractual SLAs of, each team really, you know, defining what they’re trying to strive for, for the service that they’re trying to deliver and the experience that people have. So another area, SRE, is a great one.

    Smalley: Yeah, no, that’s in there as well. SRE is certainly something that significantly contributes to more resilient operations, just like chaos engineering, another of the techniques that we reference. But speaking about agreements, certainly, you should measure stuff. Whether you—you know, the trouble is, once you put something into an agreement between two parties, people start to game the system. Things—I think it’s Hawthorn’s Law. It’s like as soon as you make something explicit, intrinsic motivation evaporates.

    Ashley: Mm-hmm.

    Smalley: Yet you do have to agree something with other parties. So, it’s really, it’s a delicate balance, you know, what’s gonna work in this situation. Also looking at the relationship that you have with your customers and other stakeholders—so, assessing what kind of relationship, what kind of agreements and measurements are appropriate for each particular situation.

    Ashley: I was thinking about, too, when you mentioned resiliency, and previously, you were talking about sort of the iterative nature, doing work in much smaller increments—that also gives more flexibility for change. So that, you may have a feature turned into a story that might be delivered over multiple iterations in an agile process, and somewhere in that process, you may have part of it released, but you may move on to other things or shift what you’re actually doing. So, it’s a way of dealing with some of the dynamic, changing needs of the business.

    Smalley: Yeah, it’s—we reference four characteristics of the approaches that you’ll find in these kind of organizations. We reference lean, agile, resilient, but also continuous, and I think that fits into this category.

    You know, things are changing all the time, so it’s interesting when you’ve got these traditional discussions between business people and IT people. You’ve got IT people almost blaming business people for the fact that the world has changed, who it’s the kind of the core values that you have, the belief system you have, if you have the belief system that things are changing all the time and that’s just part of life, that’s a given, then you don’t resist as much. We certainly try to encourage people to embrace and enable change as well. We used to talk about change—management change control, which seems to be a bit defensive. When now, it’s just language, but even then, we like to talk about change enablement—how can you get changes done as quickly and safely as possible?

    Ashley: Very interesting. Yeah, words do matter. What’s the state of the community, the ITIL community in the adoption of some of the principles around lean and agile and DevOps and SRE. Are most folks starting to become aware of or are they educating, are they practicing? Where would you say we are in this journey?

    Smalley: Yeah, well, I forget who said it. Somebody said, “The future’s already here, it’s not just evenly distributed.”

    Ashley: [Laughter] Yeah, that was Stephen Hawking or someone.

    Smalley: Yeah, that’s right, yeah. You know, some people are doing it. I’m very pleased to see on LinkedIn or Twitter a response from an organization in the U.K. that says, “This high velocity IT stuff, this reflects the things that we are doing.” This is a guy on the joint DevOps and IT service management come together. I mean, that’s his area of work.

    Ashley: Mm-hmm.

    Smalley: It’ll depend on the kind of products and services that people, organizations provide are the digitally enabled? How digitally enabled are they? So, it is very diverse. Lots of people for whom this is all pretty new, one of the things we, one of the objectives we have for the book is to familiarize people who know the old way of working, you know, working in silos, that kind of stuff, and get them used to—make them more confident, confident to engage in discussions with their DevOps, with their SRE colleagues about digital to get the conversation going.

    Ashley: It seems like that’s very important because, as things evolve, new things come into the picture—DevOps, et cetera, SRE. It’s really easy to be sort of overwhelmed of, “Now, what’s that, and how is that different and why should I care, or does it apply to me?” So, it seems that maybe taking that approach in this module of trying to bring that together from an ITIL perspective, from an operational perspective makes, maybe, those topics a little more approachable, a little easier to consume and understand?

    Smalley: Yeah, and one of the things we advise people is to look at the five objectives that I mentioned, from valuable investments to a short conformance, and discover, identify where the weakest link is in the organization or in that part of the organization. Because if you look at the theory of constraints, another body of knowledge that we reference, you should always be working on the weakest link.

    So, that helps you to focus on a particular part—don’t be overwhelmed. You can’t do all of this. You wouldn’t want to do all of this at once. Pick your weakest link, pick something that seems feasible that you can think, “Yeah, I can make an improvement, there,” and very much in the sentiment of continual improvement. Of course, one of the DevOps tenets, the third way of DevOps is continuous improvement—learning and improving all the time.

    Little steps. I think that’s the way we’d like to encourage people to go—just take it step by step. Because after each step, you refer to the systemic nature of this kind of stuff. After each step, you’ve changed the system, so you’ve got to look around and see what’s changed and then plan the next step. So, moving from what I call confirmatory ways of working in the high velocity IT books, you know, when you’ve got pre-determined plans and deadlines and milestones, because you can more or less predict what’s going to happen, you confirm that—during execution, you confirm that what you predicted in the plan happened.

    So, move—and we’re used to that in IT service management, predetermined process. So, moving from confirmatory ways of working to more exploratory ways of working, where you take things step by step—so, evolutionary. As Dave Snowden, who some people will know from the Cynefin framework, says—Dave authored a great piece about ethics for the book, by the way, but his core area is, he’s known from his complexity work—he says, “You’ve got to move to the adjacent possible in an organization.” So, sort of feel where the disposition of the organization is, in which direction are they moving naturally, and try and give them a nudge in that direction, zig-zagging towards, you know, whatever you want to achieve. That more—again, that’s that working in complex environments, reflecting the and respecting the unpredictable nature of the world we work in.

    Ashley: You know, we’re kind of borrowing from a lot of disciplines talking about this and one that comes to mind, I believe, it’s quantum mechanics that just observing something changes.

    Smalley: That’s it, yeah, the Heisenberg principle.

    Ashley: The Heisenberg principle, thank you.

    Smalley: Yeah, shine a light on it and it’s moved. You can either detect the velocity or the position, but not both at the same time.

    Ashley: Mm-hmm. Very good. Well, this has been really fascinating—yeah, go ahead.

    Smalley: I think Schrödinger’s cat came into it as well, didn’t he?

    Ashley: [Laughter] Very good. Well, you know, I think what’s fascinating about your work and the contributor’s work on this is, I venture to guess there wasn’t a lot of discussion about tools and technologies, because you’re really thinking about the how of how we do work, how we work together, how this leads to the creation of software toward  some co-created outcome.

    Smalley: It’s very much the people dimension as well. You see that just talking—I mentioned ethics, for instance. Ethics—people want to do the right thing. That’s an aspiration that people have. They want to trust and be trusted in the workplace—psychological safety. I’m delighted that our industry is talking about this kind of stuff more often. Talking about things like—I remember at a conference, you know, the good old days when we actually went to conferences, a conference in, I think it was New Zealand, in Wellington, where somebody was talking about social anxiety as a rather introvert engineer.

    Ashley: Mm-hmm.

    Smalley: And it’s great, because you know, people empathize with that, and it’s great to trust and be trusted, fostering an environment where people can feel free to express themselves without fear for their position or reputation. If you build that kind of a foundation in your organization—you know, all the tools fit into place.

    By giving people the confidence to—and the privilege, possibly a final thought, people just don’t work in IT. Some people say it, but you know, I’m sure some people don’t just work in IT, they have the privilege of contributing to the well-being and prosperity of digital service consumers, right down at the end of the chain. And I find that inspirational, thinking, you know, not just what happens in my silo, but at the end of the chain, you’re helping change somebody’s world. And that’s the kind of, that’s what I like to say about this book—it’s guidance that matters for people like us, who care.

    Ashley: Mm-hmm. It’s definitely inspiring to know that you’re helping people, right, in the work that they do.

    So, Mark Smalley, it’s been fascinating talking with you. I applaud you on the approach you took on this, a lot of great concepts that you’ve incorporated in the high velocity IT module, and I hope folks will check it out, because I think there’s some super valuable things. Again, changing the system is just by first observing it and I think just reading the module, checking out parts of it would be a step in that direction. So, appreciate your contribution, and it’s been great talking with you today.

    Smalley: My pleasure, Mitch. Thank you very much, indeed.

    Ashley: You bet.

  • DevOps Chat: Adopting Agile + DevOps in Large Orgs

    DevOps Chat: Adopting Agile + DevOps in Large Orgs

    In this DevOps Chat, Akshay Anand, ITSM product ambassador at AXELOS, and David Crouch, senior advisor at Beyond20, join Mitch Ashley to share best practices and learnings from introducing and adopting Agile and DevOps in large organizations. Akshay and David discuss overcoming change management challenges and obstacles to increase adoption.

    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. I’m joined by Akshay Anand, who’s product ambassador with AXELOS, and David Crouch, who’s a senior advisor at Beyond20. Welcome. Good to have you on, good to be talking with you.

    Akshay Anand: Thanks for having us.

    David Crouch: Thank you.

    Ashley: Great. Would you first both start out – let’s do a little bit of introduction just to introduce yourself, a little bit of what you do and a little bit about the company that you’re with, if you want to start Akshay.

    Anand: Sure. Yeah, my pleasure. Thanks for having us, as I said. My name is Akshay Anand. I’m the product ambassador for ITIL, working for Axelos Global Best Practice. Axelos was a company that was formed about five years ago as a partnership between Her Majesty’s Government and a large private sector company called Capita. We like to think of ourselves as the custodians of best practice bodies of knowledge, not just ITIL. We also manage PRINCE2, which is our project management, MSP which is Managing Successful Programmes, which is our program management, and a few others besides.

    Before joining Axelos I was a consultant for most of my career in the IT service management space across both the US and the UK. I spent a couple of years as the head of service management for Macmillan Publishing as well. And that’s me.

    Ashley: Great. David?

    Crouch: Hi. My name is David Crouch, affectionately called Lower Baltimore at the office because that’s where I live and where I’m coming to you from right now.

    Ashley: [Laughs]

    Crouch: It doesn’t come with a _____. I spent about 20 years at Johns Hopkins University and Hospital before coming to Beyond20. Finished my time there working in the IT solution center which was our service management center for excellence. At Beyond20 we are a company that focuses on digital transformation. At the core of it we really try to improve the way people and organizations work by looking at their digital transformations and looking at how to improve their IT service management processes. We do consulting work, we do training, and focusing on ITIL but also project management and Agile and DevOps and these other areas as well, and we also have a team of folks who implement IT service management tools.

    Ashley: Excellent. Perfect timing for our topic today. So let’s kind of jump into that. We’re talking about Agile and DevOps and ways that that’s introduced into companies’ best practices, learnings from adopting or not [laughs] those different practices. Maybe we can start with how we introduce or you’ve seen companies introduce either Agile or DevOps or both into organizations and kind of thinking probably larger organizations where there’s more change management involved. I imagine that’s a lot of work you get into, David. Is that correct?

    Crouch: It is. You know, we see a lot of organizations who know a little bit about DevOps and a little bit about Agile but haven’t really adopted an Agile mindset and don’t really have the full understanding of what organizational structure can really support DevOps, and yet they need these things to really support a digital transformation. So typically we’ll start with doing some sort of assessment to see where they are now to see what pain points they have right now, and then try to figure out, okay, does it make sense to introduce Agile, where does it make sense to introduce DevOps, and how quickly can that be done or how gradually do we need to introduce these concepts?

    Ashley: How about you, Akshay? I’m sure you worked with plenty of organizations that have introduced this and gone through that process.

    Anand: Yeah. I’ve actually seen broadly two major patterns. The first being where the organization transformation is driven top-down, so it’s usually a board of directors or whatever governance structure says, “Look, you know, this is the vision of what we want the company to be,” and the senior-most leadership team says, “Well, in order to be able to do that we need to be able to iterate faster, we need to be able to have much more of a focus on pushing out digital products and services,” and that change then percolates through the rest of the organization, so very much a top-down thing. The other major pattern that I’ve seen and experienced is where you might have a small team who with the help of let’s just say a more enlightened manager is given the freedom to start to experiment and innovate and change ways of working while sort of at the same time remaining compliant with the rest of the organization’s policies and what have you, and they’re able to demonstrate improvements in either efficiency, productivity, experience, whatever it might be, to the point where the rest of the organization says, “Okay, so what are these guys doing and what can we learn from that and how can we start to pick up some of those changes ourselves?”

    So in a way at that point, it’s a branch, that sort of new ways of working or new principles of working start to diffuse horizontally, so there are other sorts of teams, engineering teams, operational teams, et cetera, who start to think and work in those ways. Or it could be that the stories of that change percolate upwards, where the middle management or the senior management say, “This is interesting. Are other organizations doing something like this? Would it benefit us to roll this out a bit wider and give it the sort of support and evangelism and investment that we need in order to create a larger change?” So that’s the sort of branch, but broadly it’s two parts—top-down, bottom-up.

    Ashley: You know, I think one of the biggest challenges with introducing any kind of fundamental change like Agile or DevOps is sort of crossing that chasm between saying we’re doing it and kind of really truly embracing the spirit or the concepts or the culture of it. Have you found that also to be true?

    Anand: Well, yes there’s a difference. The way I reconcile this difference perhaps is in the following way and David probably has a completely different experience from his vantage point but for me one of the biggest challenges that organizations face or at least let’s say practitioners face, and then I’ll come to organizations—one of the things that I think practitioners are challenged by is in a way thinking that everybody understands things and just gets it. Everyone understands why we have to be Agile. Everyone understands why DevOps is important. And the truth of the matter is not a lot of people understand that and even if they do understand the words they don’t necessarily understand the implications to the rest of the organization.

    So there is a little bit of this need to manage upwards, need to manage outwards to be able to champion the need for that change, the need for these new ways of working. The other thing which I think organizations and practitioners are challenged by is understanding where these new ways of working will succeed and where they would not succeed, and this is some of the things that we do actually talk about within the sort of ITIL 4 library of guidance that digital transformation or these new ways of working are really important, yes, but in a certain context they can be a hindrance rather than a boom, and organizations need to understand where these sorts of things can work. If the work that’s being done is highly predictable or has very long cycles of work and feedback then perhaps trying to break it down might only go so far, but if you try to overengineer or impose an Agile way of working you might actually end up doing more harm than good, even though you’re starting out with good intentions.

    Certain things, to put it bluntly, don’t care how the work is being done. Once you start reaching the level of governance or supplier management or whatever it might be, in a way yes the CIOs today might say, “DevOps is really important, Agile is really important, et cetera,” but if you press them about what exactly is being done – look, I just say based on my conversations with other leaders I understand this is important, but the exact mechanics of how we’re actually going to execute on this I leave to the team who’s actually doing the work. So you’ve got to understand that change is difficult. The further up you go in an organization the harder it is going to be to try to convince somebody about the nitty-gritties that need to change, and you’ve got to be able to understand your audience, understand what they need to hear, understand how to convince them, and that aspect of communication is one of the critical components of organizational change management. It’s one of the places where I see the failure of organizational change management most commonly occur.

    Ashley: Interesting. How about you, David? Share some of your experiences.

    Crouch: You know, I think some of the more challenging but also more interesting from the consultant point of view situations are dealing with some companies that have been around for 80, 100, 150 years, and then I think folks pretty much around the globe would know some of these companies and they’re very mature in some respects. They’ve built their brand over time. But then when they start to suddenly – you know, some of them suddenly wake up and realize, “Oh, wait a second. We have gotten out of touch with what our customers really need, our external customers really need and what they want, and there are competitors that we never even dreamed of before that are entering into our space.”

    They suddenly wake up and realize not only do we need new products and new services but we also need to work in a different way to produce those because customers change their mind a lot, customers are fickle, and I don’t mean that in a bad way. We want to understand what our customers need. And then the challenge becomes, okay, well if we haven’t been doing this right now it’s necessary but not sufficient just to provide training in these areas. Training goes so far. That’s very useful, but then also where are we going to have an area where doing something like Agile software development really makes sense?

    I worked with an organization where any of what are often referred to as systems of record, so these are internal systems that keep the company running, their software team was actually doing a fairly good job because they worked in a relatively Agile way. It wasn’t 100 percent of what you would describe as Agile, but it was pretty darn good. And yet they would often run into roadblocks when they got into the more, for lack of a better term, traditional change management or as we call it these days change engagement processes where they were actually analyzing risk and managing risk all throughout the process because they were doing an Agile approach, and yet sometimes they would have this long delay at the end of the process when they got to their change control board in that company.

    On the other hand, that company almost overnight experienced some significant financial losses and significant layoffs and they very quickly needed to develop some, what we call, systems of engagement, systems and tools that their third-party paying customers would use and would purchase, and in that case, the organization bypassed their internal IT entirely and just went to a third party because the third party really was already doing some version of DevOps in that case for years. Then the question becomes does their existing IT shop still have a reason to be? The answer, in that case, was yes, but it becomes very difficult because if you tried to apply that to the entire organization, particularly overnight, I don’t think it would’ve worked very well.

    Ashley: Oftentimes in those situations, you also see people _____ project if it is an internal group just to try to isolate it and minimize the overall organizational reaction. Some people call them the corporate antibodies that tend to kick out and respond to change.

    Anand: SIt’s interesting you say that, Mitch. What I’ve also seen though is that can also work but it has to be done very carefully because – who was it, which book was it? I think Geoffrey Moore – was it Geoffrey Moore? Yeah, I think Geoffrey Moore wrote an entire book about this phenomenon, a book called “Zone to Win,” and what he was talking about in that book with numerous examples, which I’m sure we’ve all experienced, is that skunkworks, that innovation lab does really well as the innovation lab, but the moment the organization says, “Okay, how do we now scale this new innovative feature, this new innovative product and industrialize it to the point where we can offer it to our thousands, millions of customers,” that’s when it falls down because you’re changing the constraints within which a product exists, if you will. It no longer exists as a small experiment measured in terms of success as an experiment.

    It’s now got to be able to stand up to the measures of being like this industrialized product or service. So if you’re moving the yardsticks, is your product capable of actually bridging that—moving across—I don’t want to use the word bridging the chasm—is the product actually capable of moving across into that industrialized state? And what we’ve also seen through some of the research that went into ITIL 4 as well is a lot of organizations failed to make that bridge between that innovation lab and the industrialized operation.

    Ashley: I appreciate you sharing that too. It could happen very well to the external group that gets formed as well. How do you reintegrate that, repatriate it back into the organization?

    Crouch: And there’s a Harvard professor that famously kind of describes some digital transformation experiments as kind of like attaching a speedboat to an aircraft carrier. You know, they move at different speeds, and although the speed may go really fast, try to get that to translate into the aircraft carrier. It’s probably not going to happen. So it becomes—you know, the challenge is do we do a proof of concept, which sounds like an experiment to me, but if we do that can we really translate that into larger organizational success? And hard to say to come up with a definitive answer, but for larger organizations I think that what I’ve seen is that it’s been very difficult for them to do that successfully, so they have to find other ways of doing it.

    Ashley: There’s a lot of things you can look at. You can look at sort of historical what’s worked, what’s failed in the past, you can look at—I call flow—what is the momentum of the organization? Are we a metrics, are we a finance, are we—what are decisions driven by? One of the things that can also help with that is also alignment. It’s why are you introducing Agile? Other than this being an IT fad, which it’s not just that, but it could be just for that reason.

    Usually, it’s not a great reason to introduce it. You’ve got to have some real true business drivers like your example, Akshay, of we’ve got to respond to these things in market, right? The customers’ expectations have changed. That creates a sense of urgency but also purpose, like what are we trying to do differently and why and then how do we apply this?

    Anand: There’s an additional wrinkle or complication, if you will, for publicly-listed companies as well where they’ve got to report certain metrics, and if you look at any company’s quarterly filings or annual filings where they talk about the year ahead or the quarter ahead, they are using certain types of metrics to communicate their direction and their results to their shareholders, to the market, and you might say, “Look, these measures are no longer relevant for what we’re trying to do or for where we’re trying to go,” but then what does that do to the company’s confidence as a shareholder? The example I cite is when the New York Times tried to move to the digital subscription. You can’t translate print subscribers into digital subscribers or engagement.

    How do you measure the success of the digital engagement because you’re not delivering hard copy newspapers anymore? But the investors were used to seeing those sort of subscriber accounts and subscriber churn and all these sorts of things as forward-looking guidance. So there’s an additional complication from a governance and a reporting mechanism, especially if you’re a publicly listed company, and that’s why people like David have so much fun going into these companies trying to help them figure out, well, it’s not just about changing the ways we’re working; how do we educate our peers, how do we educate our managers, how do we educate our suppliers, how do we educate our consumers, how do we educate our shareholders? There’s all these different stakeholders. It’s not just about changing the way your software development is done. It has massive ripple effects across the ecosystem.

    Crouch: Well, and what’s really interesting about like New York Times is that they were still successful with their print publication, one of the few, when they began their digital transformation. So you have a tremendous amount of courage to be able to say as the leader, “You know what? We’re successful now but this is not going to last. We can see it in the marketplace. So what we actually need to do is intentionally set up a parallel operating model and say we’re going to move in this new direction.”

    And that means that that’s in their case going to siphon away, intentionally siphon away over time the way we do business now and it’s probably going to hurt in the meantime, and we’ll use any of the profits from our existing model to move over to this new model. But gosh, if you’re an investor you have to be pretty nervous about that unless you’re really in it for the long term and you say, “You know what? They’ve seen this and other companies have tried this; how do I know that New York Times is going to be successful when some of their peer publications have not been when they try to do this and for a variety of factors?” It seemed to work for them but it’s pretty daunting.

    Ashley: That’s what I would call the disrupt yourself before you’re disrupted model, right? Because usually it’s much more painful when you’re reacting to someone else who’s coming in and taking market share or whatever. That’s a really good example too of in the print media going into digital, it’s not the same product, it’s not the same consumers, it’s not the same behavior. The market really has changed, or maybe you’re just really going after a different market who would never now buy print but they would just use that example.

    So a lot of it can be driven by those things that we’ve answered about strategy or understanding of the market or shift’s that are occurring and tie those reasons as part of why we need to create software faster or why we need to create it in waves of some smaller increments to be able to respond to really rapid shifts or experiment in market. That’s another great reason to do that.

    Anand: Absolutely.

    Ashley: Well, talk a little bit about—you mentioned the speedboat. I can just imagine it tied to the aircraft carrier, kind of sort of like the fly tied to the string, right? How do you start to introduce speed into a larger organization that has a lot of momentum around the way they’ve been doing things that’s worked for them probably very successfully? How do you start introducing something like speed to say, “This is super-critical and here’s how we’ve got to operate now?”

    Crouch: I think it starts with trying to understand what they’re primarily trying to do. Where does having more speed make the most sense? So it could be we’re in a consumer marketplace and the customers are changing their minds a lot and there may be a way to develop something more quickly to respond to that need or in the perfect world to actually kind of predict and shape that demand for the great digital masters. On the other hand, some companies may say, “Well, maybe we’re not in a strictly business-to-consumer marketplace but we need to increase operational efficiencies in some areas,” and so maybe speed is more important there. And then for a few companies out there it may be both, right?

    It may be if we increase operational efficiencies on the inside of the company we can also drive the outside third party customer, and that’s no easy way to do that, to figure out where speed is going to be appropriate and where doing things quicker might actually get in the way in some cases. Akshay, I don’t know what your experiences have been there.

    Anand: I mean, look, there’s a lot of great organizational change, organization design, literature out there for people who want to read up more about this sort of thing. The Satir change model or Kotter’s Seven Steps or whatever else it might be. In my experience, one of the first steps I’ve seen in any successful change is – to use Kotter’s language – creating a sense of urgency. I guess this is something I remember from my time living in the US. Wasn’t there this sort of tagline that the first step to recovery is admitting you have a problem or something along those lines, right? So it’s kind of like that.

    The first step towards creating a change is to acknowledge that you need to change, because once everyone acknowledges that you need to change you can start to think about, well, what sort of change do we want to have? And this has to be a highly collaborative effort. It’s not just your CXOs locking themselves in a conference room at a resort for two days and whiteboarding this out. This has to be a truly collaborative exercise across the entire organization. There may need to be some constraints that are in place, and what I’ve typically seen is a board of directors might say, “Look, this is where we want to be five years from now,” not necessarily saying how that needs to be achieved but saying this is where we want to be.

    That in combination with creating that sense of urgency says, “Look, if we need to hit this sort of a target we need to be able to develop software faster or close out outages quicker or have a more Agile procurement process or whatever else it might be,” and that’s when you start to identify these sort of strategic and tactical initiatives. Because you’re working collaboratively you’re dispersing that cognitive effort, if you will. So it’s not just somebody from one particular vantage point saying, “As a CFO I think we are giving away too much money so we’re going to be cost-cutting only.” That’s a singular perspective. But once you distribute perspective you can then say, “Right, if we are supposed to meet this we have to change here, we have to change there, we have to modify that,” and so on.

    For me that is the essential first two steps; create that sense of urgency and then distribute the cognition of what needs to change. Create that collaborative series of committees, councils, call it what you will, that will help you identify in different areas what needs to change, and then you start investing to execute on that series of tactical initiatives or programs of change.

    Ashley: When I first learned about change management—David, maybe you can comment on this—we used the phrase “the burning platform.” What’s the burning platform that we’re on that’s forcing us to change or really compelling us to make a change? It can be as dangerous as are we going to exist but also it could be here’s why a two- or three-year strategy makes sense. Let’s not just communicate this strategy; let’s communicate the why.

    What’s changing? What evidence do we have of this? What do we want to get ahead of or prevent ourselves from experiencing? Have you seen that as a successful strategy for helping create that burning platform or at least the sense of it?

    Crouch: I think so. I mean I think the top level of support from the leadership is absolutely critical, but when it comes to defining the problem getting down to as specific as you possibly can. It’s not just a matter of we’re not getting new products out to customers quickly enough or it’s not just a matter of we’re not implementing enough infrastructure changes within a certain period of time. It’s a matter of exactly what about that isn’t going well and why would improving that be made better? In some cases it’s obvious. In some cases, for example, it’s not so obvious, and when people think of Agile and DevOps one of the first things that comes to mind is speed, we’re going to get more speed.

    That’s an important part of it. It’s not the only reason why you might use some of those techniques. To use a simple example, if I need to be at the theater for a show—not these days—but if I have to be there at 7:00 PM and I only live 15 minutes away, driving faster won’t necessarily improve my results. I get there—it still doesn’t start until 7:00 PM. If I get there at 6:00 PM I guess I get a good parking spot. So speed is just one element, but think about with Agile doing things in smaller iterations, controlling the risk, controlling the scope. All of these are considerations in addition to just speed.

    Ashley: What –

    Anand: And the other thing that I think the research shows us—sorry, I didn’t mean to –

    Ashley: No, no. Go right ahead, Akshay.

    Anand: I was going to say one of the other things that our research has shown us as we’ve been working on ITIL 4 and other bits and pieces, even frameworks like managing successful programs and so on, is organizations need to figure out the right duration of their strategy cycle. Now if your company is a two-person company then maybe your strategy cycle is measured in days or weeks, all the way up to if you’re the government of India and you’re trying to manage—not manage, but govern one-point-how-many-ever billion people then your strategy cycle is likely to be measured in years, if not decades. Well, hopefully not decades. So I think the other aspect that we’ve seen, at least in typical organizations, strategy cycles have gone from being sort of this thing that happened every five years to maybe things that are happening every three years because the world’s changing too fast for a five-year cycle to make sense.

    We may see a point where three-year cycles are deemed insufficient and we need to move to two-year or one-year cycles. But that’s the other trend that we’re also seeing, that strategy cycles themselves are reducing.

    Crouch: I’ve seen that a little with managed service providers, for some of the managed service providers. Even one year seems to be an awfully long time for some of them, you know? So there’s this kind of blend between are we talking about strategy or tactics here, but I agree; the timeline is becoming shorter and shorter it seems.

    Ashley: It certainly has, and of course our current COVID situation, I’ve seen some resource. I know some of the sources of this, but some have said, “We’ve accelerated as much as six years in our digital transformation strategies in the last six months.” Probably not everybody has, I imagine. Well, this has been great talking with you both. I know you mentioned, Akshay, Geoffrey Moore’s book “Zone to Win” as a great resource. Any other resources on introducing Agile and DevOps or on change management that you guys can think of might suggest?

    Anand: Well, I think I would be very remiss if I didn’t actually mention ITIL 4, which is the product for which I’m an ambassador.

    Ashley: That was a setup question.

    [Laughter]

    Anand: Easy question, though. So look, there are a couple of really good books in ITIL 4 which talk about this. Two books in particular that I’d like to highlight. The first is “High Velocity IT” and the second is “Digital and IT Strategy.” “Digital and IT Strategy” actually does refer back to some of the content in “High Velocity IT.” “High Velocity IT” is more focused on the tactics and operations aspect of introducing these new ways of working and managing the changes and the implications therein to the rest of the organization. “Digital and IT Strategy” is more about the governance and strategy and the interface to tactics, so it’s about how do you determine what’s the appropriate business model, how do you create a change in your business model and from that create a change in your operating model, from that figure out where Agile and DevOps make sense and where it doesn’t make sense and so on.

    So it’s very much the sort of top-down but the leader’s perspective of things, whereas “High Velocity IT” is the practitioner’s perspective of things. I think those two would definitely be really good. I’d also plug a couple of books like “Team of Teams” I think is really an interesting read, talking about how especially in an organization like the US Army, which you would typically think is very large and flexible and so on, how they were able to create that kind of a change, not necessarily with software development but around ways of working from across multiple teams, across multiple time zones, so that’s also a really good book to check out.

    Ashley: Yeah, I’ve not read that book but I’ve heard it’s good. I think it’s by Stanley McChrystal, right? General McChrystal?

    Anand: That’s right.

    Ashley: Great author. I think he uses his whole military experiences, examples of that, so I’ve heard him speak about it. How about you, David? Any suggestions?

    Crouch: I would just say that, you know, as one of the authors of the ITIL “Digital and IT Strategy” book I’m going to put in a plug for that. I’m just a little bit biased, even though it probably took several years off of my lifespan to help write that—I’m kidding. But no, that’s really talking more about the strategy side of things. I recall reading an article years ago as part of one of his classic books. Michael Porter talked about IT is not strategic, and I struggle with that. I agreed kind of at the time and now I don’t know, and I think if IT is now strategic in this era of digital transformation it really comes down to things like high velocity IT to DevOps to Agile to some of the techniques that we talk about in the “Digital and IT Strategy” book and “High Velocity IT.” You know, I would suggest reading that.

    Anand: There’s probably a couple of other plugs to make just before we go, sorry.

    Ashley: You bet.

    Anand: For those who want to read a little bit deeper into some of the more cutting-edge, I would say, thought leaders, read up on Simon Wardley, Wardley mapping and his whole strategy cycle stuff. He publishes that on his blog. There’s tons and tons of material on his blog, which I think he started condensing to a series of medium articles. But there’s also YouTube talks that he does. Amazing stuff. And the second is Dave Snowden and the Cynefin framework. It’s getting a lot of attention in the Agile space especially, but it’s a decision-making framework. It’s a sense-making and a decision-making framework and it has applications from business strategy to project management and everything in between, and I think that’s another –

    Ashley: Excellent.

    Anand: – at the moment cutting edge but hopefully a soon mass-market approach.

    Ashley: Oh, those are some fantastic resources. And maybe a parting thought for all of us is I don’t know if IT is strategic but I’m pretty sure software is strategic these days that’s driving – really fueling our digital transformation.

    Anand: Absolutely.

    Ashley: So a topic for another conversation. Well, thank you, gentlemen, Akshay Anand, who’s product ambassador of Axelos, and David Crouch, senior advisor Beyond20. Thank you so much for sharing your experience and your thoughts on this topic. I’m sure it’s been really helpful.

    Anand: Thanks for having us, and to the audience, you can find me on Twitter @bloreboy if you care to follow me, and I’d love to hear some feedback either through Mitch or directly, however you’d like. I’d love to know what you thought about what we were talking about today.

    Ashley: Wonderful. Happy to do that. And I’ll pass that along if we do. David, do you want to share any contact information?

    Crouch: Yeah, same here. I’m on LinkedIn. A slightly younger, bow-tied version of myself is on LinkedIn. Feel free to connect with me. Certainly visit our blog at Beyond20. We’re always writing articles, trying to grapple with some of these issues, changing our mind some of the time, but you find a lot of what I write there.

    Ashley: Excellent. Well, we’ll look forward to talking with you both again soon. Take care. Have a great day.

    Anand: Thank you.

    Ashley: You’ve listened to another DevOps Chat podcast. This is Mitch Ashley thanking everyone for joining us today. Be safe, be careful out there.

  • ITIL 4 in the Age of Agile and DevOps, With Axelos

    ITIL 4 in the Age of Agile and DevOps, With Axelos

    ITIL is well-established as the process, certification and information resource library for service management across many IT organizations globally. With the recent updates to ITIL 4, influences from Agile and DevOps are helping ITIL to expand and adapt to changes in ways to create software and build operations into the delivery process.

    In this DevOps Chat, Akshay Anand, product ambassador with AXELOS Global Best Practice, and Jon Stevens-Hall, principal product manager at BMC Software, join Accelerated Strategies Group CEO Mitch Ashley to discuss the new innovations in ITIL 4. As major contributors to ITIL 4, Akshay and Jon share the approach they took with ITIL 4, incorporating ideas from the world of Agile and DevOps.

    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. I have the great pleasure of being joined by a couple of really cool gentlemen here with a great topic I’m excited to talk with you about.

    The first is Akshay Anand, who is Product Ambassador to AXELOS. Also, we have with us Jon Stevens-Hall, a Principal Product Manager with BMC Software. Welcome, gentlemen.

    Akshay Anand: Thanks for having us.

    Ashley: Yeah, I’m excited to talk with you about this. We’re gonna jump into ITIL, ITIL 4, and some of the work that you’ve been contributing to that, but first, why don’t we start out—Jon, would you introduce yourself, tell us a little bit about what you do and a little bit about BMC Software? I’m sure many people know that, but just for the folks who don’t?

    Jon Stevens-Hall: Sure. So, I’m the Principal Product Manager for BMC’s enterprise ITSM suite, which, you know, it comes from the Remedy heritage family of products, now titled BMC Helix ITSM, and I’ve been around service management for over 20 years now. I sort of walked out of university into my first job in the late ‘90s, implementing systems for ITIL 2 over at what became Yell Group.

    And so, I’ve been around service management and ITSM for all that time, and obviously, my primary role at BMC is producing and creating software and tools, but also, we always try to be active members of the ITSM community in general, which is what led me on a personal basis to being one of the contributors or ITIL 4.

    Ashley: Mm-hmm. Awesome, excellent. And Akshay, how about you?

    Anand: Oh, so, I joined AXELOS about four years ago. AXELOS, for those who don’t know, is a joint venture between Her Majesty’s Government and a private sector company called Capita. We like to see ourselves as the custodians of the IP, of not only ITIL, but other best practice arrangements like PRINCE2, which is about project management or MSP which is about program management. I’m Product Ambassador, so like the product evangelist for ITSM and ITIL in general. My background is mostly around consulting in the IT Service Management, consulting and advisory. I’ve also been Head of Service Management for Macmillan Publishing for a couple of years. And yeah, like I said, I joined AXELOS four years ago and it’s been a blast.

    Ashley: Excellent, excellent. Well, I’m sure that consulting, and also Jon, your experience with BMC gives you some real-world perspective on ITIL and ITIL 4.

    Well, talk about the publications that you’ve contributed to the IP. I think the Create, Deliver, and Support around ITIL 4 is one of the areas that you both contributed. Do you wanna jump in first, Akshay?

    Anand: Sure. So, Create, Deliver, and Support is one of four books in a learning stream that we call Managing Professional. All the books in that sort of learning stream are oriented toward managers or professionals who are either managing or designing systems, service management systems. Create, Deliver, and Support in particular talks about things like employee engagement and professionalism, a lot of the commonly used tools needed to create, deliver, and support services, things like value streams, value stream mapping, how to apply value streams within the context of ITIL 4, how to manage suppliers.

    So, it’s a very wide-ranging book, but it goes into a lot of detail about very, very specific techniques. Two of those techniques were actually authored by Jon, and one was around tickets and the use of tickets or the misuse of tickets and what to avoid, and the other was actually around swarming, and how swarming can be a good model to use within service management organizations, a technique that can be used to foster collaboration between development and engineering teams and frontline support teams.

    Ashley: Interesting. Jon, love to hear about that. I know, just to share you a bias about tickets, I think everybody’s impression of IT is, you can’t talk to IT unless you complete a ticket. Well, maybe that’s taking it a little bit far, right? [Laughter]

    Stevens-Hall: No, that’s definitely a true impression. I mean, one of the things I’ve spent much of the last six years doing is really, I’m a bit of a method actor, I’ve been very immersed in the DevOps community. And almost, I joke that I went to my first DevOps conference by accident because I signed up for something called Configuration Management Camp thinking, you know, ITSM, CMDB, configuration management. I soon learned very quickly we were talking more Puppet and Chef and Ansible.

    Anyway, and it was fantastic, because it’s opened up a door into a world that has evolved somewhat differently. And there were many aspects of culture that I think IT Service Management was not understanding very well, which was one of the reasons I was very keen to bring my kind of cross-domain perspective to ITIL 4, because I think a lot of us felt ITIL—bear in mind that version 3 originated before DevOps, it needed a big refresh. And that example of tickets absolutely is true. I mean, people sort of see this negative perception that, you know, to get infrastructure, we used to have to raise a ticket and wait three weeks—now, we can log onto a software-defined infrastructure tool and we can create it right away and it’s all delivered on cloud.

    And absolutely, I mean, one of the—you know, we sometimes, I think the heritage of IT has created these impressions not in a vacuum. You know, they’re not false impressions sometimes. But I mean, ultimately, what is it? You know, a ticket is just a data record that represents a piece of work, and a lot of the work we’ve done around developing systems at BMC has been to try and sort of take away this old way of very sort of skeuomorphically presenting a form to somebody who did all the fields on that piece of work, you know, all the things about that.

    And I wrote a blog on this a year or two ago where I likened it to an old taxi booking service I used to use in California if I flew to work, where you had to kind of fill in about three pages—box, box, box, box, box. All those things are important pieces, probably, for the taxi operator, but you know, this is the world where I can open up my smartphone and press one button and get a taxi, you know? I don’t have to care about all that stuff.

    Likewise, I think where we’ve had to move on is to sort of—you know, what we’ve had to learn as a community on the service management side and maybe, you know, have to convey more to the DevOps world is that, you know, we all record units of work, we just don’t have to necessarily present it in such a complicated way. And we can,  you know, we should focus on the actual flows and the people and not this sort of big-ticket data problem. You know, we probably still want to know that you’re deploying infrastructure, but we don’t have to make you fill out a great big form to do it.

    Ashley: Well, and software engineers kinda think in terms of Kanban cards and stories and epics, you know, applying agile kind of things. Have some of those concepts, then, creeped into the idea around tickets within ITIL 4? Is there some intersection of those ideas at all?

    Stevens-Hall: Yeah, I mean, [Cross talk]—go ahead, Akshay.

    Anand: Oh, I was gonna say, in general, I think we definitely had a lot of inspiration across the entire ITIL 4 contributing team, whether architects, authors, reviewers, et cetera. There were definitely a lot of people who pulled on a lot of lessons learned from the world of agile software development, of DevOps, and of lean, and we tried to incorporate a lot of that thinking into ITIL 4.

    It may have been there in ITIL version 3, but it possibly wasn’t at the forefront, it wasn’t embedded at the heart of the framework. But what we did with ITIL 4 was to say, “Look, these are important, you know? We need to be able to reinforce continual improvement, we need to be able to reinforce elimination of wasteful work. We need to reinforce, you know, that we’re working in complex environments.” Especially as we’re working in environments which are, at this level of service management, is a mix of human and non-human interactions, and that is inherently complex and we need to reinforce things like iterative progression and the role of feedback in such a system and so on.

    So, we brought a lot of those lessons in. Whether that was sort of very foundational models that we used in subsequent publications to present and frame certain arguments or whether that was highlighting specific techniques like Kanban or—I’m drawing a black, sorry, I haven’t had enough coffee. But highlighting specific techniques like Kanban and others in other publications.

    So, there’s another publication called High Velocity IT, and coincidentally, Jon was a contributor to that as well. And in that, we talk about how certain techniques can be used to meet certain objectives in high-velocity service organizations like fast development or creating faster feedback loops at the service level. Sure, we have it at a technical level, but we also need to be able to mirror that or replicate that in some shape or fashion at the service level. So, we definitely try to bring in as much of that foundational thinking from lean and agile and other best practices or emerging practices and bake that into ITIL 4.

    But for the specifics on how we did that is, with queueing and swarming and so on, that’s a lot of the stuff that Jon helped author.

    Stevens-Hall: Yeah, and I think one of the big—I mean, taking a step back from just the concept, you know, the rethinking about things like tickets, one of the things I’m very happy, one of the reasons I was happy to get involved with ITIL 4 was that it’s shifted a lot of thinking, and again, learning from DevOps and lean in particular and making us think much more about value than process and control. And, of course, that’s been a challenge for us to position that we’re thinking that way, but ultimately, I want to sort of talk about the positive things.

    You know, I talked to developers in the DevOps world who see huge value in people taking some of the leg work off their workload, you know? So, we all know that those developers are delivering the most value if they’re innovating the developing. If we can bring service management techniques, better align it with DevOps so that any of the support tickets that are coming the developer’s way, you know, the issues that inevitably come up when the—and especially as DevOps in enterprises goes from sort of small little startup exercises to big and normal and widespread, suddenly, those developers often find themselves doing half of their work resolving issues that have come in, you know, come in from the monitoring or from people. And one thing that service management has done extremely well for a long time is help to kind of industrialize and produce high quality support channels.

    So, what we are in a great position to do is actually, you know, with that focus on value, you know, in a lean culture, if it’s not valuable, why the hell are we doing it, by kind of moving on from some of the old concepts, but taking all the things we’ve done very well and working with the DevOps community with a much better understanding of the way they’ve learned, you know, drawing up their lessons, but at the same time, pushing the fact that there is huge value that we can deliver to help them do what they do, then, you know, suddenly, this IT service management and the ITIL framework, I’m in a much better position to help those things. And I’m seeing people who are very skeptical before now saying, “Actually, this is how we unlocked the organization’s confidence and give them that ability to go faster with DevOps.”

    Ashley: You know, it’s really heartening to hear that’s the approach that you both have taken with this, because it seems, you know, there’s sort of the impression of process for process’ sake where, no matter what we’re talking about, and of course, you know, many folks that are in this highly iterative—right, there’s process in the way we create software that way.

    But if the service management and the software creation processes can better mesh together, right, so that it’s not viewed as an impedance when someone gets a ticket, right, and has to conform to an old process—but it flows with how we develop software and release the change that might go through that. I think maybe that’s that continuity that we start to see between ITIL and DevOps and lean and agile to help everybody see how it can benefit what we’re doing.

    Anand: I remember a conversation with a gentleman called Greg Sanka, who is the CIO of Oregon State Administrative Services. This is a conversation maybe last summer, and we were talking about the guiding principles that we introduced in ITIL 4. In particular, we talked about focus on value. As a principle, we need to be able to focus on value—Jon has just referred to that, as well.

    But what we are talking about is, nobody—very few teams are consistently sure on what value means and how value changes from person to person. So, of course, there’s value for customers who are using the software and the applications that we’re deploying. But there’s also value for your risk officer, there’s value for your supplier, there’s value for your CFO.

    Now, a lot of these people aren’t involved in the actual use of the software day to day, they’re not involved in the development of the software, et cetera, but we’ve got to be able to architect the solutions, the service management wraparound, et cetera, et cetera to be able to create that value.

    Now, part of the reason why sometimes IT service management and ticketing that you were mentioning has a bad reputation is, that’s how that assurance was created at a certain point in time.

    Ashley: Mm-hmm.

    Anand: But we now have to go back and say—look, because technology has changed, we’ve removed certain risks that we were trying to mitigate 10 years ago, but we’ve introduced new risks that we didn’t have 10 years ago.

    Ashley: Mm-hmm.

    Anand: So, what does that assurance now need to look like? How do we re-architect our systems to accomplish that same assurance? How do we introduce more automation, remove the toil, et cetera, while providing—in order to provide that assurance?

    Stevens-Hall: Yeah, it’s almost like the ticket was almost the kind of, the manifestation of the internal memo in a digital system, you know, the old paper memo. I mean, I’m old enough to remember those envelopes where you crossed out the old address and put the next one on and it went around the internal mail system.

    But, you know, it is important to remember that these processes actually helped us to move that kind of customer support in the technical world from adhocracy and Post-it notes to a proper, robust, scalable solution. That moved us on to self-service, to knowledge management, to properly established professional ways of handling and resolving issues that are now extremely valuable when DevOps goes big in organizations and it hits the mainstream and it hits a large volume of users and starts having to deal with support issues.

    The more staff we can use these established service management practices—albeit modernized, heavily rethought, you know, focused much more on value than process for process’ sake? The more we can do that, the better—and this is proving itself over and over again with our customers—the better it actually helps us to enable DevOps to go, you know, to accelerate, to deliver that huge value that we know it can create.

    Ashley: Well, it seems like the, some of the process and the auditability, if you want to think about the benefits of why you have processes, right, so consistency and reaction to issues and resolving them—those are some things that can actually benefit people that are working in a philosophy environment, because sometimes that can be a bit chaotic, or it’s just extremely fast. Obviously, things are happening very quickly.

    And then when you need to start interfacing with other parts of the organization, whether it’s, you know, do we do vulnerability scanning for the security group, you know, how are we handling resolution time for production issues? That’s where that intersection can really be helpful, and some of those well-defined processes and ways of measuring value from an operational standpoint, development teams don’t have to do that, because you’ve already done that through, or are in the process, right?

    Stevens-Hall: Yeah, and also one of the good things in ITIL 4 that we’ve been able to do is actually learn very much hands-on from DevOps. So, one of the big subject areas that’s really growing in interest on both sides, as it were—and I kept on using the word “sides,” but you know where I’m coming from—is this idea of using a more swarming technique than kind of the traditional structures.

    And so, this is a really good example because, you know, very traditionally, service management has kind of operated a three-tier support structure where you’ll kind of have a front line at tier one, which we’ll try and probably mostly successfully fix most minor things, you know, then if they can’t, they’ll escalate to a more expert level, tier two. You know, back in the day, that would’ve been the service desk agency who then did their Microsoft certificates, for example, and became a slightly more specialist team.

    And then things that can’t be solved there, you know, 5, 10 percent or whatever would end up with tier three teams who are more likely to be developers, specialists. There’s nothing wrong with having those teams, but what is wrong is a couple of things. You know, the first is that issues can often take a long time to get to that team, because what we’re effectively doing is putting queues in the way, you know, so it goes into the tier two queue. Someone then has X hours or days to pick it up, so it sits in that queue. It then goes to tier three and sits in a queue, and by the time it’s got there, we’ve already got an angry customer, even though everyone might have met their operational agreements, the other thing that happens is the sort of ping pong effect where, you know, if it goes to a tier—these things that get, especially, to the tier-three level, they might need input from several development teams. They might need a database team to have input to it, they might need a network team or whatever.

    And with these kind of traditional silos, although they’re, if the ticket’s not gonna leave that silo, it’s absolutely the right place for it to be if the issue, I should talk issues, but things ping around and you end up with problems like champions emerging who’s the one person everybody knows can fix it every time, and so they pay their mortgage off in overtime, but they always look a bit unhealthy, and then they leave the company and everybody’s in trouble.

    So, swarming has helped us, actually, it really is taking much leaner techniques. It’s about sort of being more dynamic in the way things are brought together as a team, you know, tearing down some of these silo structures, and in particular, removing queues of unfulfilled work in progress.

    Ashley: Describe for us—

    Stevens-Hall: And that way, we’re really learning directly from lean, we’re really learning directly from the DevOps focus on having much better flow and reducing handoffs and, in particular, not letting things build up in queues.

    Ashley: For someone who’s not familiar with swarming, describe how that would work in this context.

    Stevens-Hall: Okay, well, I mean, at BMC, we’ve done this in our own customer service team for a while, and what it effectively means is a couple of things. You know, you’ll always have kinda, the most severe issues have always pretty much been swarmed everywhere. And that’s, you know, everything’s on fire, so we’ll get everybody we need into a room and we’ll sort it out. And so, that’s always kind of been the most basic form of swarming, even though we haven’t really called it that. And that’s not really where the novelty is.

    For us, the novelty is, we’ve collapsed that tier one and tier two, so instead of having that kinda chain where somebody fairly qualified takes a look and then if they can’t fix it, somebody more qualified takes a look, we kind of put those two people together. And instead of waiting for things to trickle through queues, we look at the things as they’re coming in, but the support people will, maybe every hour, just look at what’s coming in that hour and be very reactive—okay, we can fix those three things, we’ll just get it done—will qualify the rest very well. And you get this lovely sort of information sharing between the two levels as well. So, they learn from each other. I think pair programming is an interesting analogy from the modern software development world.

    So, that actually increases the flow very significantly through those first—you know, it gets things fixed quicker and it increases the throughput. Then when things do go to sort of the tier three product specialist groups, they’re not allowed to start assigning it around other tier-three groups. So, if they’ve got one of these more complicated issues, instead of doing that, they’ll pull together a group of people into a swarm and work it that way.

    And it’s all—they’ve got a lot of leeway to be very self-organizing which, again, probably doesn’t sound like the impression that service management have always given. So, it’s not that rigid, you know? They will figure out what works best for their team. So, we have some teams hold three sessions a day at fixed times and people can come in with issues. We have others that spin things up on a more ad hoc basis, but the interesting point is there, again, things are not going from bucket to bucket, you know, queue to queue, they’re being owned by the person who takes command of them and we’ve found there’s really great engagement, people coming together in a Microsoft Team session or on a call or face to face way back when. And again, it looks a lot more like the kind of practices that have evolved in the DevOps community. So, again, we’re learning to sort of focus on delivering the value rather than focus on hearing sort of a pre-defined, rigid process.

    Ashley: Mm-hmm. I’ve been there, actually. I know you were trying to—I think I may have stepped on what you were gonna say, so jump in.

    Anand: Oh, no. I think it works. As Jon was saying, you know, back in the day or probably even still to this day, you know, every time there’s a priority one incident or a severity one incident or one of those really big things, you know, everything’s on fire type of thing, you know, we used to call it a war room back in the day, we used to have conference breaches back in the day.

    You know, so that technique was perhaps limited in its application, but we’re now starting to see how that same technique is being, if you will, scaled-down or right scaled-down to the appropriate size and being used across the support organization and not just limited for use to, you know, the building’s falling down type of issues.

    Stevens-Hall: And one of the great things that’s happened as we’ve sort of distributed this messaging and talked more about it is, actually, it’s got huge engagement in DevOps community. I’ve presented on this at a number of DevOps events, you know, right up to DevOps Enterprise Summit.

    Because actually, what I believe it’s doing is, it’s sort of showing the DevOps community that there is, not only is the support, the world of kind of technical support and service management, you know, that sort of structured technical customer support and service management, we’re looking to try and offer value to the DevOps community, but we’re also doing it in a way that is much better aligned with the way the DevOps community has learned to work. And, you know, so rather than those developers ending up just being treated as a third line support team and having things thrown over the fence to them, it enables us to kind of bring a much more collaborative system together and reduce those kind of pockets of those silos where knowledge doesn’t escape.

    So, the value—again, thinking about the value—the value, again, to those teams working in the DevOps world is that we can actually be embedding support people much closer to what they do and those support people learn how to fix the issues. And then when there’s more of those issues, those support are there as professional support, you know, as support professionals who are good at this kind of thing can be figuring out ways to proactively resolve those things, automate those processes, move towards customer self-service as an ultimate goal, perhaps, or self-healing and get those developers developing.

    Ashley: Yeah, it also gets them more—I’d say more closely aligned to knowledge about what the application is, how it’s structured, who to contact, you know, help them maybe even diagnose more of the issues themselves.

    Stevens-Hall: Yeah, so again, it perhaps creates some parallels with what, again, companies like Google have innovated with site reliability engineering. It’s not quite the same, you know, these are not necessarily developers and I often caution people from kind of just saying you can just do SRE, you can get service management kind of spaces like the service desk and do SRE. You’re not really doing SRE in the strict sense the way it’s known in the DevOps community where it is kind of developers doing proactive things with infrastructure.

    You know, if you look at an SRE job spec, it’s gonna be a bunch of programming languages and related experience, but we can still take, again, those learning principles, you know, the idea, for example, of thinking in terms of ERA budgets, you know, so rather than every failure being a major—you know, every time we lose a bit of our remaining availability budget against that target, you know, that could be, that’s always been seen as negative, I think.

    But what SRE has introduced is the concept of actually using some of that spare availability capacity to be proactive and make things work better. I like—an analogy I do is, “Why don’t we take somebody off the service desk calls for an hour?” It means our call pickup percentage is 98 percent instead of 99 percent, but they could spend that time doing something that really, really drives improvement.

    So, again, these techniques that have evolved in DevOps really sort of cross-pollinate well in the service management space and enable us to better connect to the way DevOps works. And, again, help them develop.

    Ashley: Mm-hmm. Well, excellent. This has been fascinating. I’ve really enjoyed talking, and I’m sure the audience does, too, that’s listening in. It’s great to talk to the contributors, to the authors of this, because you get the benefit of both, you’re writing a knowledge that’s shared in that medium, but also—what was the thinking behind it? What were the influences and how did you get to those conclusions and sorta that context is also super helpful. So, this has been really great. I’ve enjoyed talking with both of you.

    Anand: Same here.

    Ashley: Great. Well, my thanks to Akshay Anand who is Product Ambassador with AXELOS and Jon Stevens-Hall, Principal Product Manager at BMC Software. Thank you, gentlemen.

    Stevens-Hall: Thank you.

    Anand: Thanks, Mitch, and thank you for listening to us today.

  • Mainframe and DevOps in Traditional Enterprise, With ASG Technologies

    Mainframe and DevOps in Traditional Enterprise, With ASG Technologies

    The assumption that large, established enterprises—from insurance companies to government agencies—can’t adopt Agile processes or DevOps is based on the falsehood that legacy technology stacks won’t allow for it; that existing traditional mainframe applications or legacy applications that large enterprises are built on are incapable of adapting to these approaches.

    Accelerated Strategies Group recently released the new research report, “5 Crucial DevOps Strategies For Cloud and Mainframe 2020,” sponsored by ASG Technologies. In this episode of DevOps Chats, Jeff Cherrington and Anna Murray with ASG Technologies joins Mitch Ashley, CEO of Accelerated Strategies Group, to explore how mainframe app teams embrace DevOps, its processes and tools to equip software teams so mainframe apps continue to provide businesses with vital systems and capabilities far into the future.

    The audio file of the conversation is below, followed by a transcript. Enjoy!

    Transcript

    Mitch Ashley: Hi. I’m joined by some special people, some folks that I really enjoy working with from ASG Technologies—different from the ASG that I work with. [Laughter] So, I’m joined today by Jeff Cherrington and Anna Murray. Thank you, both, for being here.

    Jeff Cherrington: Well, thank you very much, Mitch. I’m Jeff Cherrington, I’m Vice President of Product Management for Systems with ASG Technologies. Many of you may know ASG. We’ve been in enterprise infrastructure management software for over 40 years, and certainly hold a prominent position as well in enterprise content management. We’re very keen to have the conversation today around how traditional infrastructure—meaning the mainframe—aligns with new DevOps initiatives in the enterprise.

    Anna, if you would introduce yourself.

    Anna Murray: Sure. Hi, my name is Anna Murray, and I’m a Senior Product Manager with ASG Technologies, and I work with Jeff Cherrington. And I have extensive experience with automation across platforms and data centers, as well as agile transformation for teams.

    Ashley: Excellent. Jeff was saying before we started that he used to work in radio—you can tell. [Laughter]

    Murray: [Laughter]

    Cherrington: [Laughter]

    Ashley: You’re very comfortable behind a microphone—no doubt, no doubt. We were talking about everybody’s on video these days, so that’s awesome.

    Murray: Right. [Laughter]

    Ashley: Well, great. You know, we’ve been doing some work together and we do have a report coming out to kind of pre-announce that. We’ll be talking about that a little bit later. But there’s a lot of myth about DevOps and mainframes. I know even some analysts—I won’t name any names—have said they’re two different paths, you shouldn’t try to do both. I think the jury has started to change their mind on that.

    Why do you think some of those myths have existed of, “No, we can’t do DevOps on mainframe environments?” Do you wanna start, Jeff?

    Cherrington: I think I will, and then I’m sure Anna’s got some thoughts that she’ll want to contribute. You know, it’s certainly a reality within the industry that we’re going through a generational shift around our leadership or IT, whether it’s infrastructure or application development. There are those who are still working daily, like myself, who represent the traditions of IT from the very beginnings back in the 1960s, and then there are others who are certainly much younger and certainly have much different experiences, which may not include any exposure to the mainframe. And, as a consequence, there might be some resistance, there might be a little bit of anxiety about the technology, and it can be formidable to approach if you don’t have the appropriate background.

    The things that we’d love to talk to, though, is that the mainframe as traditional technology still performs incredibly important roles within the enterprise. And at the end of the day, DevOps is much more about technique than technology, and it can apply as easily to mainframe and should as it does to any other part of the IT infrastructure.

    Anna, do you have some thoughts to build on that?

    Murray: Sure. You know, as I think about the generation gap that you’re talking about, I kind of come on the other end, but I’m Gen X. And so, we were the generation that said, “Oh, the mainframe’s dying,” right? [Laughter] So, that—obviously, I’ve learned that’s totally wrong, and the generation coming after us is coming in to learn the mainframe and realize how powerful it is, right?

    And so, I think a lot of the leaders that are coming in are coming from this generation that didn’t even think about mainframe for a while, right? And so, they did all their planning and their agile transformation and their DevOps transformations thinking about the cloud and all of their Windows and Linux and Unix servers and didn’t even think about the mainframe.

    And so, I think that’s the other side of the gap that happens. As the younger leaders are coming up, you know, especially, I would say blame my generation the most, right? [Laughter] Because there’s this gap, and—learn more and make sure you’re talking to both ends of the spectrum and learn about crossing the gap.

    Cherrington: And actually, the way I like to phrase it now is far less to use jargon like “generational gap,” but instead talk about generational bridge, because that’s what I’m seeing.

    Murray: That’s so much better, yeah.

    Cherrington: We’re seeing that the younger IT professionals are identifying that there’s great opportunity to work with mainframe in the coming years. And so, we see Millennials, or is it Gen Y—the generation after yours, Anna—who are stepping forward and saying, “This is really interesting. The mainframe does all of the technologies, it supports all of the technologies that I learned in uni, university. I can do Java, I can do TCP/IP connections, I’ve got great sources for strong cryptography, it supports Unix, I can put Linux onto a mainframe LPAR—this is a good space to be in.”

    And so, more and more, we’re seeing that the people we engage with are a mix of people that are my age with the white beard or the gray beard and a mix of young, fresh faces that are really eager and really excited to get involved, and who come predisposed to new techniques such as DevOps.

    Murray: Mm-hmm.

    Ashley: You know, there’s so much important things that both of you said. One is that in DevOps, there is no technology definition of what it applies to, and it’s very easy to associate it with Cloud Native and maybe newer applications, because that’s where it sort of grew up initially.

    But DevOps is really about how we create software, not what technology we use to create software. And it’s about how teams collaborate, it’s about how you share information, it’s about how you get different functions from the business together in a collaborative team to kinda do things earlier in the process, do automation. All of that applies to the mainframe, of course, and there’s tools to do much of what we’ve talked about. Maybe you can say a little bit about how people approach DevOps in the mainframe environment.

    You wanna go, Anna?

    Murray: Right? Well, you know, when you approach DevOps in the mainframe environment, it’s not so much just about the mainframe environment, but the company. The whole organization has to be behind DevOps, and there has to be leadership saying, “Hey, this is something we need across silos,” right? And then you have to look at the tools available to you. DevOps is a lot about the toolchain itself. There’s hundreds of tools in that toolchain, and so, you have to start looking for solutions that are gonna meet your needs and help you cross those silos.

    Cherrington: You know, it’s certainly true that everybody resists change. I think that’s an innate part of human nature, but both Anna and I have seen that things of this nature can come forward, can be used with teams that are mainframe-centric, perhaps have been doing things the way they’ve been doing them for 10 years or 20 years or 30 years.

    And there’s natural resistance. “Gosh, you know, I’ve done things the way I’ve done them successfully for so long, why should I change?” Certainly, I’ve seen agile adopted by mainframe development teams, sometimes kicking and screaming, but once the resistance curve is overcome, it becomes very productive and becomes very natural.

    And I think we’re at that stage now in terms of adoption of DevOps for the entire enterprise infrastructure, from Windows all the way to the mainframe and onto the cloud and even onto mobile, even as there are initial reactions of going, you know, “How can this apply? This is not something I learned when I went to my classes to learn more about the mainframe at SHARE in 1995 or 1985.” But we have proof points.

    We have large international enterprises, we have small regional enterprises that are coming forward and saying, “I must have mainframe. It plays a critical role for things that I need to do, particularly around payments processing, anything that needs highly available, real-time online absolute reliable performance. And it is only part of my infrastructure, and I need to treat how I develop there the same way I treat developing anywhere else.”

    Ashley: You were talking about, also—so many apps are not just a mobile app, right? There’s a whole back end to it, oftentimes sharing data, even talking transactions between multiple systems, one of those or multiple may be mainframe applications. You know, and if I step back for a minute and think about our current environment and how much things have accelerated in doing sort of these digital transformation, digital experiences for customers, organizations are looking to both strategically move quicker, but also be able to react opportunistically and sometimes based on conditions. And it seems like some of the flexibility with DevOps makes it easier to coordinate some of those activities across multiple applications. So, if you do have to do three different release to make up one new capability, that comes together much easier.

    Cherrington: It does. You know, the thing that I always look to as I engage with anything around business is, to use an old phrase, “why is the juice worth the squeeze?” And while we talk about DevOps a lot because of its elegance, because of its collaboration, because of the ways in which it makes development easier, the real juice of the squeeze is time to market. The whole reason to consider DevOps is how can we get something we need to get in terms of new technology enablement to market quickly, more quickly than we did before, but not sacrifice quality.

    And that’s what we see time and time again is, we have something we need to get to market. I want to present new capabilities to my customers through an app on the phone because that’s where people live their digital lives. But at the back end, it’s dependent upon the mainframe for things such as account balances, customer statuses—an unending list of capabilities that still remain on the platform as the best place for that type of activity to occur.

    Ashley: Mm-hmm. You know, I’m thinking about just the recent experiences with the reactions to COVID and contactless delivery, inventory, product inventories are often something that’s still on the mainframe, has been for a long time, and now, you know, retail stores, as well as a lot of others, have to be able to maintain a really accurate enough inventory and also present that to the customers so they know, what store can I go at to pick up whatever I’m looking at buying.

    I’m curious, too—I know that ASG Technologies has some of your own products, your own technology around this idea of orchestration across platforms because you work both mainframe and non-mainframe environments. Talk to us a little bit about how you approached coming up with that product and maybe a little bit about how it works and what it does.

    Murray: Sure, I’ll jump in for a little bit here. You know, you talk about orchestration—that’s combining your toolchain, right? You’ve got all the little pieces of your DevOps toolchain, and you need to figure out how to connect all the dots and bring it together and, you know, ASG has been doing automation and orchestration for a long time, but we’ve changed our focus into bringing in the development part of that toolchain, right?

    Operations has been kind of a focus of automation for a long time, and now we have to pull in all of the development pieces that happen and the configuration management that happens, and all of those—there’s lots of little tools there, right?

    So, we haven’t tried to come at the market as trying to provide all the tools, but we’re trying to provide some of them, right, and we definitely want to orchestrate as many as possible, right, and cover the entire environment for the customer. On the mainframe, the most popular thing we’ve been working with recently is JCL Management. Every mainframe’s running JCL, right? Nothing happens on the mainframe without it, and so making sure that there’s a DevOps interface to your JCL Management solution is really important. And so, we’ve made an investment in making sure that ours has both an Eclipse plug-in that makes it easier for the developers to interface with that JCL as well as a RESTful web service API so that it can be integrated with building of the products and crossing across the silos to other products.

    Ashley: Mm-hmm.

    Cherrington: And certainly, in the approach that we’ve taken, we look to be a good citizen of the DevOps enterprise community, and the work that Anna and her team have done, we ensure that we support the most popular integrated development environments for doing this sort of work. So, the JCL quality assurance and management offerings that we have for the mainframe are also certified for the Compuware Topaz integrated development environment and for the IBM—what’s the name of it again, Anna? It’s—

    Murray: IDZ.

    Cherrington: IDZ. What was the rational development environment that’s now rebranded?

    Murray: Yes. [Laughter]

    Cherrington: As well as any other Eclipse compatible IDE that a customer may want to use.

    Ashley: You know, it’s interesting, just thinking about all the, a number of the terms that you both used in just those last two comments, you know, mainframe 10 years ago, you wouldn’t have been talking about, I don’t think, RESTful IDE—all the tools that we kinda think of as sort of in cloud applications, much of it is the same toolset, a lot of the same ideas, just working with integrating some other different tools that are specific to the mainframe environment.

    Cherrington: It is, and you know, I certainly want to encourage those who are listening and watching—and particularly, those who may be ASG customers now or are considering becoming ASG customers—to join us at our worldwide customer conference, a virtual conference this year, EVOLVE, that will be occurring on October 6th and 7th, because we will be making some significant announcements about extending support in this area, including opportunities for creating interfaces to mainframe applications that can extend all the way to mobile, if that’s of use to a customer.

    We’ve had a lot of excitement coming into this, we have a lot of partners and customers who are going to be presenting, and there’s a great deal of energy that we’ll be putting forth around our DevOps support and DevOps enablement.

    Murray: And can folks sign up? How do they register to attend the virtual conference? Is that on your website?

    Cherrington: It’s on our website if you come to www.asg.com, I’m sure you’ll find something right on the home page that says EVOLVE 2020 and it’ll give you the opportunities to get, well, involved.

    Ashley: [Laughter] EVOLVE and involved at the same time.

    Cherrington: Exactly. [Laughter]

    Murray: [Laughter]

    Ashley: You know, the fact that you get to work with so many organizations that are adopting DevOps, I’m kinda curious about two things. How does the mainframe teams approach wanting to learn about DevOps and coming up to speed and trying it, and then how do the existing practitioners maybe outside of the mainframe group that are also using DevOps—how do they see what’s happening in the organization and how do they…do they want to participate, do they support it, are they kinda not sure? What do you see happening, there?

    Murray: So, yeah, you know, there’s a mixed feeling. You know, there’s definitely differences between, you know, if it’s led from the top down and people are being told they have to change, right, it depends on how you’ve adjusted the expectations in your team, right? Helping them learn what’s coming and why instead of just telling people what to do makes a huge difference, right?

    Ashley: Mm-hmm.

    Murray: We’re all much more interested in solving problems and learning new things together. So, it’s really important conversation is held properly, right?

    So, we have some that are really excited that they want to learn and they want to jump in from the mainframe side and grow, and then there’s others that are really just struggling and pulling their mainframe teams along, right? So, one customer I think of, you know, is standardized on Compuware Topaz Workbench, but the developers are less interested in switching over. They have some of the older generation who’s very comfortable with the green screen and they think, “Why bother switching to Topaz?” You know? They just don’t even get it.

    Ashley: Mm-hmm.

    Murray: And so, you know, the truth is, we really need to have solutions that meet the needs of all of the people that are part of the DevOps environment, right? So, it isn’t—you know, a very experienced mainframe programmer doesn’t have to use Eclipse, right? They can be quite happy on the green screen and we should let them stay there, right? [Laughter] And we do, our JCL Management solutions have a very robust green screen interface, and then we bridged the gap, as Jeff was talking about earlier, with having those APIs, right?

    And so—yes, so the DevOps toolchain is still brought together with something like our ASG Enterprise Orchestrator pulling in the code and grabbing with the API the JCL and making sure that the standards are applied and then bringing them across for compiles and distribution into another environment, right? Not that you compile JCL, but there’s other parts that are related.

    Ashley: Mm-hmm.

    Murray: So, you know, you asked—it’s kind of a mixed bag. And we see that, too, right? And as the conversation becomes more common, right, I think we’ll have more people who are more comfortable having that conversation and learning together.

    Ashley: Excellent. Well, Jeff has been bitten by the Zoom bug, so he had to call in from his call dropping, so glad you’re still with us, Jeff.

    Cherrington: Mm-hmm.

    Ashley: You know, we were just talking about the adoption process, and Anna, you were talking about how mainframe teams kind of approach this. I’d like the other side of it. DevOps teams that maybe aren’t in the mainframe group that have been practicing this for a while, maybe a few months, a few years—how do they see this happening, and is there collaboration? Do they pitch in, do they tend to work together or not? How does it go?

    Cherrington: Well, some of the things I’ve seen actually goes to either end of the spectrum. For the teams working with the more modern technologies and have to adopt DevOps very frequently, we find evangelists, those who have gotten to the point where they believe in the techniques and the approaches so passionately that they’re out there actually promoting them everywhere they can. It’s much like what we saw with the adoption of agile in the last decade. We’re seeing that same sort of passion surround this approach to development in this decade.

    You know, it’s one of those things, we have to keep in mind—DevOps was not even a term within the industry until 2009. I mean, it’s barely a decade old, and it’s in these last five years that we have seen the acceleration for adoption.

    Now, having said that, you know there certainly are always going to be pockets within any enterprise where, again, there’s resistance. There are those who are not looking for change and those that, perhaps, while they have embraced the DevOps approaches for their distributed systems or cloud development, look at the ideas of what they have to change or adapt to on the mainframe side and really don’t want to go there. The idea that there might be a long compile that has to be done on the mainframe before the next step in the DevOps process can occur will cause some—a little bit of agita.

    And that’s why it’s so important we need to take a look at the strategies that are necessary for DevOps success. I think that’s something that you speak to very eloquently, Mitch. And out of those steps, the one that I think is so critically important is culture shift. Just like with agile adoption, DevOps adoption needs support from the top, and it needs to be constantly vocal support to help people pull through these resistance curves. Resistance curves are natural and the quicker an enterprise gets through them, the quicker they get to a point that they’re delivering new capabilities to market much more quickly.

    Murray: Right.

    Ashley: Thanks for your kind words about the culture, too, and I want to get your thoughts on this, Anna. Culture is a lot of things, but I think we’re all human at the end of the day and none of us want to look dumb, right? We don’t want to tackle something we don’t know if we can learn or maybe not kinda look so good in front of our peers if we’re the ones behind the curve.

    And I think something that can help combat that is, one of the principles of DevOps is sharing, is really—it’s collaborating, but it’s also sharing. Sharing scripts, process, tools, content, methods—all of those kinds of things which, if you truly adopt DevOps, as you said, Jeff, you can become an advocate and then also help with that transition and very quickly, you know, they kinda get over that curve of, “Okay, alright, I’m not—I’m familiar with this,” as you mentioned, Anna, I can still use my green screen or many of the tools that I’m already using and I’m just adding to kinda what I’ve been doing.

    So, your thoughts, Anna?

    Murray: Right, well, I’ve recently been having other conversations with partners about this culture shift and it’s become really clear with other companies that are supporting DevOps and those initiatives that you really have to have not just buy-in from your senior management, you’ve got to have active support. You know, they have to sponsor the change.

    Because we’ve also seen companies who don’t go through the change, they fail. If it’s from the bottom up only and the senior leadership says, “Okay, yeah, sure, that’s a great idea,” but they’re not actually investing in it themselves, the team, when they hit road bumps—because they will. It’s not, you know, switching to DevOps doesn’t happen overnight. I think we all know that. And over time, you’re gonna hit roadblocks and you’re gonna get discouraged. And who is it that’s gonna lift you up?

    Now, hopefully, there’s evangelists that’ll help keep pulling you through and encouraging you, but at the end of the day, if your senior management isn’t coming back in to say, “Hey, guys, we believe in this process, it’s worth fixing, we’re gonna invest in whatever it takes to solve this problem,” then they’re encouraged to keep moving forward, right?

    But, you know, there is the difference happening out there where the leadership isn’t always invested in it. And so, that’s what we’re really encouraging when it comes to that culture shift that has to happen, make sure that you get not just buy-in but investment from your senior leadership.

    Ashley: Mm-hmm. Hugely important and it goes back to the, “Why are we doing this question?” that you talked about also, Jeff. You talked about really responding quickly and getting software out to market or quickly in today’s situation with COVID and uncertain as well as very quickly changing conditions, you know, something could very easily come down from Product Management or whoever to the development teams and say, “Okay, we need to add this capability or change how we’re doing something.” And the team’s ability to react quickly—I mean, they already do today, but even more quickly under these circumstances, I think, demonstrates the value not only of DevOps, but also those teams.

    Cherrington: Absolutely. Absolutely. I mean, it’s always a virtue to be able to get to market quickly. And in the current period of the pandemic, it’s a virtue that actually can impact lives on a broad scale.

    As the different national governments are taking the steps that they need to take to provide stimulus and secure the safety of their populations during all of this disruption, one of the things we’ve seen is that there have to be changes to critical traditional mainframe systems for all of this to happen. Certainly, the unemployment compensation that was distributed here in the U.S. touched legacy traditional systems at the state level that perhaps have not been actively developed for some period of years.

    And certainly, those government enterprises or commercial enterprises that were pre-prepared to apply their DevOps techniques to making those changes to their traditional offerings, traditional applications were better prepared to deal with this and to deal with the ongoing change as our government’s tried to figure out how to stabilize economies and get us through this challenging time.

    Murray: Mm-hmm.

    Ashley: You’re absolutely right, and that’s one example of many. I mean, there’s insurance claims processing to get your request fulfilled quickly, you know, new medicines—all of that kind of thing. There’s so many areas where mainframe technology is involved today.

    Well, I wish we could keep going. Maybe I have to come to the conference to continue the conversation. [Laughter]

    Cherrington: [Laughter]

    Murray: Yeah, we would love that.

    Cherrington: You would always be welcome.

    Ashley: Well, I appreciate that very much. And so, just a reminder for our audience, the EVOLVE conference is on October 6th and 7th. Go to the ASG.com website to find out how to register; I absolutely recommend doing that. And as I mentioned earlier, we have a research report coming out and the working title of that report, I think, was “Five Critical Strategies for DevOps and Mainframe.” So, we’ll see, maybe that title will stick or something close to that. I’m excited to get that out because that’s been a great effort working with you.

    Well, Anna Murray, thank you very much; Jeff Cherrington, also—thank you for joining us today.

    Cherrington: Thank you so much.

    Murray: Thank you, Mitch.

    Cherrington: And folks—stay safe.

    Murray: Yeah.

    Ashley: Alright.

    Murray: Alright, thank you.

    Ashley: You bet.

  • DevOps Chat: Software-Defined Storage, With StorPool

    DevOps Chat: Software-Defined Storage, With StorPool

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

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

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

    Transcript

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

    Boyan Krosnov: Hi, Alan.

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

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

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

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

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

    Krosnov: Yeah, okay.

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

    Krosnov: Yeah.

    Shimel: And what’s your position with StorPool?

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

    Shimel: Sure.

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

    Shimel: Someone has to do that. Okay.

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

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

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

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

    Shimel: Mm-hmm.

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

    Shimel: Yeah.

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

    Shimel: Yeah, everyone already has some data.

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

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

    Krosnov: Yeah.

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

    Krosnov: Yeah.

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

    Krosnov: Yeah, yeah.

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

    Krosnov: Yeah.

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

    Krosnov: Yeah, yeah.

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

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

    Shimel: Really?

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

    Shimel: Right.

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

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

    Krosnov: Mm-hmm.

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

    Krosnov: Yeah.

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

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

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

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

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

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

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

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. We’ve got some exciting funding news on today’s DevOps Chat. A company I’ve been familiar with now for a few months, Armory, Armory.io—is it Online Networks, DROdio, or just Armory?

    DROdio: Just Armory.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: Absolutely.

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

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

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

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

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

    DROdio: Yeah. [Laughter]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: Fantastic.

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

    Landers: Absolutely.

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

    DROdio: Perfect.

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

    DROdio: That’s right. [Laughter]

    Shimel: [Laughter] Fantastic!

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

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

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

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

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

    DROdio: Yeah.

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

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

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

    Shimel: My pleasure.

    Landers: Thank you, Alan.

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

    — Alan Shimel

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

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

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

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

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

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

    Transcript

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

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

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

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

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

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

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

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

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

    Ashley: Mm-hmm.

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

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

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

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

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

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

    Ashley: Mm-hmm.

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

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

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

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

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

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

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

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

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

    Ashley: Mm-hmm.

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

    Ashley: Mm-hmm.

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

    Ashley: Right.

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

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

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

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

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

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

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

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

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

    Ashley: Mm-hmm.

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

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

    Andrzejewski: Absolutely.

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

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

    Ashley: Mm-hmm.

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

    Ashley: Mm-hmm.

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

    Ashley: Mm-hmm.

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

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

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

    Andrzejewski: Definitely, yep.

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

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

    Ashley: Sure.

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

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

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

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

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

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

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

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

    — Mitchell Ashley

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

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

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

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

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

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

    Transcript

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

    Marc, welcome to DevOps Chat.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Schwartz: Yeah.

    Shimel: Your thoughts?

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

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

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

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

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

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

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

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

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

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

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

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

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

    Schwartz: [Laughter]

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

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

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

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

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

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

    Schwartz: [Laughter]

    Shimel: It’s on a roll of reminders.

    Schwartz: Excellent sound effects.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Schwartz: Uh huh. Sounds great.

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

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

    Schwartz: Thank you very much.

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

    Schwartz: Thanks.

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

    — Alan Shimel

  • DevOps Chat: We Are Devo, With Walter Scott

    DevOps Chat: We Are Devo, With Walter Scott

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

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

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

    Transcript

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

    Walter Scott: Thanks, Alan.

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

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

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

    Scott: That is correct.

    Shimel: Give us a little background on that.

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

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

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

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

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

    Shimel: I agree.

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

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

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

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

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

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

    Shimel: Yep.

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: Nice.

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

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

    Scott: Great, Alan. Thanks.

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

    — Alan Shimel

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

    DevOps Chat: OPA and the CNCF, With Torin Sandall

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

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


    Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

    Shimel: Absolutely.

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

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

    Sandall: [Laughter] That’s okay.

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

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

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

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

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

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

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

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

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

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

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

    Shimel: Mm-hmm.

    Sandall: And so—

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

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

    Shimel: There’s not a single vendor.

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

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

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

    Sandall: Right, yes. Yes.

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

    Sandall: Yes, yes.

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

    Sandall: Tekton?

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

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

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

    Shimel: Yeah, yeah, yeah. [Laughter]

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

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

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

    Shimel: How do you spell that?

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

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

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

    Shimel: Oh, I’m sorry. Okay.

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

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

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

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

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

    Shimel: Really?

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

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

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

    Shimel: Got it.

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

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

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

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

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

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

    Sandall: Yeah.

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

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

    Shimel: Yep, I remember that one as well.

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

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

    Sandall: Yeah, that would be great.

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

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

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

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

    Shimel: Excellent.

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

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

    Sandall: Perfect! Yeah, looking forward to it.

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

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

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

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

    Sandall: [Laughter]

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

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

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

    Sandall: Yep.

    Shimel: —OpenPolicyAgent.org?

    Sandall: That’s correct, yep.

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

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

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

    Sandall: [Laughter]

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

    Sandall: Will do.

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

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

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

    — Alan Shimel