Tag: machine learning artificial intelligence

Artificial intelligence (AI) and machine learning (ML) help improve the performance of DevOps teams by automating repetitive tasks and eliminating inefficiencies across the SDLC. By using AI, teams can test, code and check software faster and more efficiently. In this episode of DevOps Unbound, Brian Dawson, Judith Hurwitz, Alan Shimel and Mitch Ashley discuss how AI and ML are transforming DevOps and what new use cases await AI and ML in 2021 and beyond. The video is below, followed by a transcript of the conversation.

[Intro Music]

Alan Shimel: Hey, everyone. I’m Alan Shimel, CEO of MediaOps, devopsy.kinsta.cloud, Container Journal, Security Boulevard, and you’re watching DevOps Unbound. DevOps Unbound is sponsored by our friends at Tricentis, so many thanks to them. And DevOps Unbound is a biweekly show where we cover topics of interest to the DevOps audience.

I am the host. My cohost is our CTO and CEO of Accelerated Strategies Group, my friend Mitchell Ashley. Mitchell, welcome.

Mitch Ashley: Thank you. Good to be here as always, and with this illustrious panel.

Shimel: Absolutely. And an illustrious panel it is. We have two panel members joining Mitchell and I today. Let me introduce you to both of them. They’re both great folks in their own right and I’m going to let them introduce themselves.

Let’s start with our friend Judith Hurwitz. Judith, welcome to DevOps Unbound.

Judith Hurwitz: Thank you so much, Alan. It’s a pleasure and an honor to be here.

Shimel: It’s our pleasure.

Hurwitz: So I’m Judith Hurwitz. I’m the coauthor of 10 books. Have been in the industry for 30-plus years. Focus on everything from DevOps, security, manageability in cloud, hybrid cloud, and really looking at how you take technology to transform organization. It’s a complex topic, not easy, but it’s what we’re in the middle of.

Shimel: Absolutely. Then last but certainly not least, our friend Brian Dawson. Hey, Brian. Welcome.

Brian Dawson: Hey, Alan. Thank you. Good to be on with you again. To tell the audience a bit about myself, as I’ve told you before, Alan, I’ve been in software development and delivery for about 30 years. I consider myself a technologist. And even prior to focusing on DevOps I’ve had a focus on optimizing software development and delivery.

Excited to talk about AI. I kind of dabbled and dipped my toes in the space in my time that I spent at the company that is now PlayStation. Things have come a long way since. And during that time, I’ve spent the past 10 years of my career focused on identifying, applying, and spreading DevOps practices, so I’m excited to discuss the two together here with this group.

Shimel: Absolutely. Brian, I’m not sure if you mentioned your present position with the Linux Foundation.

Dawson: I did not actually, because also this organization I’m at today has a big footprint in the AI and ML space. So today I’m with the Linux Foundation. I oversee our developer relations and ecosystem development. And of note, within that is the LF AI & Data Foundation, which houses a number of impactful projects in this space.

Shimel: Thank you. I just thought the folks at LF would welcome that, a little plug for them.

Dawson: Well I appreciate it, thank you.

Shimel: Yep. Alright. So the topic for today’s DevOps Unbound is artificial intelligence and machine learning. How can they help improve performance of DevOps teams? In other words, what’s their role in the DevOps world? Right? And let me preface our conversation by giving you sort of my view of it. DevOps for many people was all about automation.

What can we automate? Let’s automate everything we can. Automate, automate, automate. And obviously in discussions around automation topics such as artificial intelligence and machine learning you would tend to think help with automation, and therefore anything that helps with automation is good for DevOps. And I should also say that we lump AI and ML together like they’re Siamese twins joined at the hip, and they’re not necessarily cojoined.

You can have AI without ML and you can have ML without AI. At least I think so. I’d be interested in your thoughts. But has it lived up to the hype? Will it ever live up to the hype? Was the hype unfounded? Was it unrealistic?

What role has AI and/or ML to this point played on DevOps and what will it play going forward? I think that’s our topic today. Any one of you, if you want to kick it off with your own feelings or respond, go right ahead.

Dawson: Well I’d like to jump in as a troublemaker early on and say I challenge Alan that DevOps is really about automation as kind of the basis for the tie-in. If we look at it, DevOps is really a set of cultural practices and tenets that align DevOps and other software delivery stakeholders around the shared objective of delivering quality software reliably, rapidly, and repeatedly. Now the reliably, rapidly, and repeatedly component absolutely lends itself to some of the benefits that we could mine from AI, but I actually think it’s a great opportunity. If we don’t say DevOps equals automation equals AI, or rather we say DevOps equals a culture aligned around a shared objective and how can AI and ML help support those shared objectives.

Hurwitz: I think you make a great point, Brian. I think one of the most important issues, and you mentioned culture. We have been for, what, 50 years through this development and operations perspective on how we get things done, and the promise of AI is, okay, I can push a button and it will take care of everything, and this promise has been there for, what, 20 years. The reality is it’s just not that simple. There are definitely things that we are doing today and we’re seeing evolve that is definitely helping the developers and the operational professionals.

For example, if you have repeatable functions that happen all of the time, that, for example, if you press a button and a certain task should happen you can probably use a model and collecting massive amounts of data to do that automatically. And that’s a very good use of AI. We’ll work today – they call it MLOps or AIOps, and there’s a good reason why that’s what we’re focused on today, is because you’re looking for predictable patterns and predictable anomalies so you can avoid making stupid mistakes that, oh my god, why did I do that? I knew what the right answer was.

But AI is not a panacea. And I think if we look back even two or three years ago, you had companies that all were saying, “Okay, we have automated, we’ve put AI into DevOps, and all you have to do is press a button and all of your problems are over.” That’s just not reality.

Ashley: There’s the marketing AI and ML and then there’s real AI and ML. Marketing meaning everybody gloms onto the term and uses it in, let’s say, a case statement or an if statement in people’s logic and their software. Yeah, I started doing some work in AI in ’80s and ’90s programming in LISP and PROLOG and doing some corporate education in that area, some expert systems with triage, things like that. So I dabbled in a little bit there and then I was exposed to more recently about five or six years ago, worked with a gentleman named Dr. Bernard _____ who’s one of the experts in the field. And I asked him, “Help me understand why has machine learning taken off as a service.”

He described it as a subset of AI, so that was his model anyway. What he told me really made sense and it kind of helps me understand where can we apply machine learning, and being kind of the most popular part of AI. He said machine learning takes massive amounts of data, and the fact that we have the cloud and all these applications creating data, a lot of the data exhaust, now people are going back and mining that data. So Judith, in your writing, in your books about data analysis and leading up to AI, machine learning is great for that because you can have supervised or unsupervised algorithms, supervised meaning that’s a cat, that’s a cat, that’s not a cat, or unsupervised which is just going to pour through the data and start to look for those patterns and trends and anomalies that you were talking ab out, Judith.

So when people talk about using AI or ML, in our industry I always think about where’s there’s lots of data and can we leverage it in some impactful way? So as I look at products or technologies that claim they’re doing that, that’s at least one sort of criteria to sort of ferret out. Is it real there? Is there something real there? Or is it more spin and fluff to help us – you know, we all have case statements in our spot, right?

Shimel: Absolutely. Actually, Brian, it looked like you were going to say something. I didn’t want to jump on you.

Dawson: Alan, of course I have a lot to say, but nothing in particular. Since I’m off mute, I’ll say I absolutely agree with Mitch and Judith and underscore the points that they made.

Shimel: Yep. You know what? I want to take a moment though and explore. Brian, you disagreed; DevOps isn’t about automation. And I get the whole cultural aspects of DevOps and all of that, but certainly automating as a way to be more efficient, to get more done faster, I think is part and parcel of the DevOps mindset.

Dawson: Yeah. And if I may, without waiting to see where you wanted to go with that, I’d say it is absolutely important, but there’s a line Jez Humble would use in talking about CD. And frankly, I think the book that Dave Farley, Jez Humble and team wrote around continuous delivery is undercelebrated and under referenced. And in talking about that, one of the things he said is continuous delivery, and I’m going to say by extension some aspect of DevOps, don’t require any tools. I can do continuous delivery with a Bash script. The catch is is it’s not the most efficient in pursuit of effective collaboration, of delivery velocity so you can iterate.

And as we’ve talked about in this past established, that controlled feedback loop, that requires things like automation to achieve those goals. Right? I just think sometimes when we talk about what we see going on with AI and ML and those terms we overload a principle or practice with expectations that aren’t core to it, and I worry a bit about that so I wanted to call it out. And sorry, Alan, I don’t know if that’s where you wanted to go with the commentary.

Shimel: No, no, no. I want to go wherever you want to go, Brian.

Dawson: Okay. [Laughs]

Shimel: This is a collective. Judith, what about – I’m sorry, go ahead.

Hurwitz: Oh, yeah. So Alan, I think one of the key issues is the whole area of continuous delivery. In previous generations, you would build an application and it would live pretty much as it was written, could be for 10 years. Today, applications are constantly having to be revised because customers change, partners change, the sources of data change. So unless you have the ability to constantly update and change and modify, you lose out. One of the values of using automation and using AI and machine learning models with lots of data is to support the ability to do this.

You don’t have enough hands and enough brains to anticipate where problems may occur because you’ve changed things. How many times have we seen problems occur because somebody has added a new service to their environment and somebody forgot to change a configuration file? Now that’s not something that you need a massive brain to be able to do, but people get busy and they forget to do simple things.

Ashley: I think, Judith, that’s a really good point, because I wanted to ask you about this in the software creation process. Given things are so dynamic now and constantly changing, understanding just the environment, the infrastructure-as-code all the way up through the application and how much all of that is changing, it seems like stepping in for humans in certain conditions in that environment is a great application of AI. For someone to synthesize all the factors that might go into where a problem exists or what might be causing a problem seems to be where some of those algorithms might be helpful. Do you agree with that? Has that been your experience of what people are thinking about for AI?

Hurwitz: Yeah, definitely. I think what we’re seeing is this is where sort of the human factor comes in. You set it up so that if the printer is turned off don’t send me an alarm, fast, emergency, there’s a problem with the printer. We all have gotten used to that. But when there are problems that you’ve never seen before, that you don’t have data on and the model doesn’t take into account, then the AIOps or MLOps then gives you a message there’s something strange going on. I don’t know how to fix it.

What do you want to do here? And so over time when that appears again, well now you had data this occurred once before. Maybe it was an anomaly twice. But then when you have enough data and enough experience over time then you build that into the model, so the next time that occurs you make a fix. On the other hand, you don’t want the system to say, “Oh, I know what that is,” make a fix, when it turns out no, no, no, you don’t understand the context of what’s going on here. And just because there’s a correlation doesn’t mean that there’s a cause for that.

Shimel: That’s a good point.

Ashley: It’s not always about automating a response to it, right? Everyone in the security world are very cautious or skeptical about those things happening, blocking legitimate traffic. In the financial world that’s a huge issue that we run into. So you point out a good scenario, whereas we see repetitive patterns over time and that can help machine learning algorithms now understand, okay, that’s what that pattern looks like. So you can identify what it is next time instead of it’s just an anomaly.

Dawson: Yeah, it’s interesting, Mitch, that you say that. And going back to the starting topic about AI and ML not really achieving its promise yet, and as you called out getting data as an issue, it’s not necessarily applicable to every space. You need a level of determinism and predictable patterns that you can learn from and build on. And I have for a long time been excited that when we look at CI and CD, when we look at, Alan, the automated workflow of software development and delivery, or even if it’s not automated kind of the standard, there’s a couple of things that you do have.

You’re doing builds, sometimes thousands a day, builds and deployment, getting that out into prop. You could be generating a ton of data. And also in its nature, you’re striving to achieve a level of consistency and repeatability in how you deliver software. And I’ll say I’m not an expert to the level some of the people on this episode are, but I get at a very top level get really excited about the opportunity for AI and ML to help better CI and CD and align with the principles of DevOps. What I see it really helping is reducing cognitive load so developers can focus on coding, innovating, and solving problems while helping ensure that quality and stability that’s difficult to maintain while you’re moving fast.

So just thought I’d call out, and I am curious to see when vendors and others really start to do like what our friend Kohsuke has done with Launchable, and really apply AI and ML to the left-hand side or Dev side of the process to reduce the load and ensure quality and stability.

Shimel: Guys, we’re all lumping AI and ML, AI and ML, AI and ML. Does it have to be AI and ML? In my experience, a lot of what we call AI and ML is a lot more on the ML than it is on the AI. Right? So it is fair to call it truly AI? Is it really ML? And maybe ML is for today and AI is a tomorrow thing. I don’t know.

Hurwitz: So I think there’s definitely a problem of nomenclature here. What we’re really dealing with primarily now is models and modeling data and creating models from data. That’s the reality of today. I think that there is a lot of misuse of the term AI. There have been some absolutely wild predictions. I can’t remember the name of the computer scientist who predicted that he would be able to replicate the human brain –

Ashley: Marvin Minsky.

Hurwitz: – with AI. No, this was past Minsky.

Ashley: Oh, was it after? Okay.

Hurwitz: Yeah. This was like in the last five years.

Ashley: Oh, okay, okay.

Hurwitz: So over time, you’re always going to be dealing with models. You’re never going to get rid of the models. AI is sort of the next – models are a subset of what you eventually achieve with AI. But AI is really a concept that will probably take decades to evolve, and I think one of the problems we have right now is where you have vendors, and I’ve talked to hundreds of them over the years, where they say, “We have an AI application,” because it’s a hot buzz word.

And you can look back and in the history over the last 30 to 40 years and see whatever the hot topic is all of the vendors say we do that. So I think that that’s one of the problems that businesses are facing right now. What is the difference? What does it really do? How does it make your company better? How do you use this technology to be prepared for change?

Ashley: I think that’s a good way to break it down, Judith, too, because early days of AI were about emulating human thinking. We’re still long from – I’m not sure – all my intelligence is artificial, by the way. I acquired all of it. I don’t think I was born with any of it. But that was kind of where it started, and then AI became about expert systems largely. And then algorithmic learning, machine learning algorithms, was really where I think most of the activity is today because of that prevalence of data.

It seems like most organizations are faced with sort of one of three strategies. What do we look for from our vendors and how they may use AI in a meaningful way or machine learning in a meaningful way that’s going to help my business? Do I build models myself from the data, like you were talking about, Judith, to apply to like a financial analysis kind of situation? More of an expert system. Or do I use machine learning algorithms in my own software to do interesting and valuable things that my software can do? And maybe you play in all three of those or a subset of those, but that seems to be the question I think most individuals or organizations are at.

We’re not at a place where we can go build models, but we’re looking for these capabilities either in our own code or in third party products.

Hurwitz: So I heard an interesting story from one of my clients a few years ago, maybe five years ago. He had a client that was very gung-ho about AI. So he went out and he hired five data scientists, paid them $1 million each, gave them their own space, and left them alone. These are the smartest people on the planet. Came back in six months.

He didn’t want to bother them, they’re so smart. Alright. What have you found out? Have you written this application? And they said, “Well, we’ve been discussing this for six months and we have determined that algorithm we’re going to use.” The point is that they worked in isolation, they thought they were the smartest people on the planet, they did not talk to people on the business side about what business problems they had, they didn’t talk to the people who understand corporate data, they didn’t ask them what data do you actually have, what data do you need, they didn’t talk to people who knew the business strategy or the business processes that were in place or needed to change.

So it really is a team sport, and I like Brian’s discussion in the beginning about culture because it really is about sort of hybrid organizations where you have leaders that know a little bit about all of these areas and then a team that’s brought together that can work across these areas.

Shimel: Fair.

Dawson: Judith, can I ask do you have any recommendations for DevOps teams on how to evaluate or investigate where ML is a solution? And I ask this based on observation – we’ll see if we agree – that oftentimes people are looking for a problem to apply the solution to as opposed to for ML as a solution to a problem they’ve identified. I’m just curious if you –

Hurwitz: I violently agree with you. So I think a lot of times people get so enamored with new technology that they look at it as a way to solve all problems. And for a DevOps team I think we’re finally getting to the stage where there’s really reality in DevOps. It’s not the developers who are saying, “That’s not my problem; the operations people have to make this work.” There’s really beginning to be this collaboration between development and operations, and this shift left is definitely becoming real.

So that’s definitely true, but for these teams to be successful they have to have a holistic view of where is your business going? What do they actually need? Why have they come to you and say we’ve go to do something? Is it just because it would be cool to do something and spend money or is there a real rationale behind this that they need? What’s the pain that’s out there that they can solve.

So they have to start with that. They have to start not only collaborating between developers and the operations team but with the business leaders, with the people who understand all of the data, people who understand security. So all of this comes together in very much a holistic pattern.

Shimel: Fair. Fair. Hey, guys, we’re way past halfway through here and I wanted to kind of turn our conversation to the future. We’ve had a discussion on sort of the history of AI and ML and lessons learned, et cetera, but when we look forward, Brian, you mentioned the Linux Foundation has, I don’t know if it’s a daughter foundation or a subgroup dedicated to AI and like technologies. What do we see when we look sort of near-term future? Forget, yes, one day we’ll mimic human brain patterns. Who knows if we’ll be alive by then. But near term, what do you see? What is Linux Foundation planning for?

Dawson: Well, so looking forward, and it’s funny because you brought me in and I started to think about dream the impossible dream of what’s going to happen in the future, I will call out and will mention again I said at the start the Linux Foundation is a parent foundation of what we call a Linux Foundation open source project that hosts other projects. So LF AI & Data, you can call it a sub foundation of Linux Foundation because they host, I believe at this point, 12 graduated projects with about 20 to 30 projects in incubation. So we’re talking 30 to 50 projects under the LF AI & Data umbrella that are all working on various aspects of shared efforts, multiple large commercial organizations as well as standards bodies coming together to drive the future of AI and ML.

What I do see coming out of LF AI & Data Foundation in the short term is standards and foundational implementations, i.e. moving sort of beyond the rudimentary discovery around AI, building packaged or gray box implementations that everybody agrees and collaborates on, which I think will help unlock the less initiated, less expert vendors to begin to deliver truly AI-based differentiating capabilities. So to put that in short, because it was a lot of words, is I think it’s about establishing a foundation for us to start to build on and accelerate our progress within the AI and data space applied to DevOps.

Hurwitz: And so Brian, I think that you’re 100 percent right, and that’s when commercialization really happens is when we have those standards and when everybody agrees to use those foundational services. I think the challenges that we face are how to get the commercial vendors who don’t necessarily want to – they want to give lip service to these standards but they really want you to only use their version of the quote/unquote standard so that customers never leave. So it’s that stickiness factor that they are looking for. So I think it’s a hard journey.

Dawson: Yeah. Well I think, Judith, you actually nailed the reason the Linux Foundation exists frankly, and if we look at Kubernetes as a model, it was hard pressed. Google could’ve easily said, “We’re not going to hand this over to the Linux Foundation. We’re going to dominate this space. We are going to be the modern cloud OS.” But they understood for it to gain traction, for it to grow and truly offer benefit industrywide, they had to hand it over to the Linux Foundation to grow and manage.

They had to bring in Microsoft, they had to bring in Amazon to play in that space. And I see LF AI & Data serving that same role, what I tend to call in some language unlocking innovation, or as our tagline is, decentralized innovation. I would beg to say that that is – we didn’t call that out directly, but that’s one of the challenges that we’re seeing in the AI and data space. If there’s not short-term monetization we’re not going to do it, and if there is then we want to own it. So can we create an impartial playing field for everybody to come in and innovate together, and then build commercial solutions off of that.

Hurwitz: Yeah, it’s a challenge. It really is. I think Kubernetes is a great example. I think data in some ways is more complicated because data is really the crunch.

Dawson: Yeah. Well I know everybody wants to own it. Everybody wants to own the data.

Shimel: No doubt about it.

Ashley: There’s also discussion about AI needs to become an engineering discipline as opposed to this sort of edge specialty. It doesn’t mean that it necessarily is going to be applying everywhere, but I think how we apply AI to certain kinds of problems. It seems to me the two most ripe areas are that highly complex environment. So with more and more infrastructure that’s automated, more things have gone to digital, how do you manage the infrastructure or manage the triage problem solving? And then of course the other areas, people will find _____, continue to find _____ where AI can be applied to gain competitive advantage in a certain domain or space.

And it seems like that’s the trajectory we’re on for quite a while. I don’t think it’s ever going to be AI takes over everything and it’s the thing that replaces DevOps or whatever. But it seems to me kind of a tool. Sorry. Go ahead, Judith.

Hurwitz: No, what I was going to say is very interesting. If you look at healthcare, for example, if you look at the spectrum from I can automate certain DevOps functions that are repeatable, where I can identify patterns, and as I collect more data I can automate more things, you have something like healthcare, which in terms of orders of magnitude of complexity are just huge. And what I’m seeing is a lot of the vendors who think that I’m going to tackle healthcare with AI and we’re going to own the industry, a lot of them are getting out of the business because right now it’s just too hard and it will be too hard for quite a while.

Ashley: That’s true. The medical industry in many ways [laughs] is a hard nut to crack.

Dawson: Yeah. If I may start to dream a little and chime in based on something you said, Mitch, I do see that in the near term we are at a point where we talk about modern software development and delivery, the rapid pace with which we’re delivering change. We’re building on inventions and progress made over decades. Library reuse is very heavy. We are getting to a point where as we build more complex systems we have to figure out how can we outsource sort of maintenance and management, for want of a better word, to use it kind of grossly to solutions like ML?

How can ML help us continue to improve, grow, and build on what we’ve done but manage the scale and complexity? And I think we’ll move from some standardization, foundational blocks, we’ll apply more ML in both the operations and development space to help manage that complexity to maintain stability, but then I also eventually see the next stage being now how do we apply ML and surface it to a developer at the time of a commit? Here’s the expected outcome of this change is, to help provide guardrails to the developer, the end state – or I wouldn’t even say the end state.

I think we’d agree existentially there’s never an end state. We’re at a point where we don’t even have explicit CI/CD pipelines. We can commit code to a repository, the language can be inferred, we can give cues or signals to infer where we want it deployed, how we want it deployed, and I actually see ML and to an extent layers of AI just figuring out what to do with code at rest. So if you flash forward in 10 years and we’re truly applying these to technologies at scale in the cloud, I’d just change a line of code.

That change automatically is delivered to production and AI and ML is helping us do that. So that’s sort of my dream. I don’t hit compile, I don’t hit build, I don’t build out stages and workflows. I just change code and that’s running in a system somewhere.

Hurwitz: So don’t you also want to have the ability to say before you say – you look at what’s happening, and don’t you want to sort of at least at this stage say are you sure you want to do that? Are you sure you want to delete that pile?

Dawson: Yes.

Hurwitz: So until we get to the point – because you have to be able to trust that the system is smart enough to understand if I make this change what cause will that unleash? Because we’re not dealing with a perfect world in DevOps by a long shot.

Dawson: Yeah. I do want that. I want protection. I want it to know where the vulnerabilities are and warn me, and I do think, Judith, that would be a prerequisite into this deploying code at rest or truly applying Dev AI.

Shimel: Fair enough. Hey, guys, we are just about out of time. I think this was a great discussion. If there’s one thing I could take out of it though is that the crystal ball remains cloudy in terms of how this is all going to play out, and we’re going to have to wait for it to kind of come into focus. But it certainly will be an important part of software development, of operations going forward, and it’s an increasingly important part. But for now though we’re –

Ashley: I think the crystal ball is a Magic 8 Ball. Ask again later.

[Laughter]

Shimel: Right, ask again – that’s a good one, Mitch. But for now, we’re going to call an end to this episode of DevOps Unbound. Again, thanks very much to Tricentis for their sponsorship. Thank you so much, Judith, thank you so much, Brian, for appearing here and we hope to see you on a future episode. Mitch, as always, great job riding shotgun with me.

Ashley: Good to partner with you. Absolutely.

Shimel: Absolutely. But this is it for this episode of DevOps Unbound. This is Alan Shimel. Have a great day, and we hope to see you soon on another DevOps Unbound as well as don’t forget every month we do a live roundtable open to you, our audience, with questions. So stay tuned for that as well. Take care, everyone. Bye-bye.

[Outro Music]

[End of Audio]