devopsy.kinsta.cloud

Category: AI

  • EP 19: How AI/ML are Used in DevOps Today

    EP 19: How AI/ML are Used in DevOps Today

    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]

  • Mona Allies with New Relic to Converge MLOps and DevOps

    Mona Allies with New Relic to Converge MLOps and DevOps

    New Relic and Mona, a provider of a platform for monitoring the models used to provide artificial intelligence (AI), announced today they have formed an alliance to help bridge the divide between DevOps teams and data scientists.

    Most data science teams today build models based on machine learning algorithms using operations platforms that enable them to manage the life cycle of those models, otherwise known as MLOps. Mona provides a set of monitoring tools that are employed to detect drift that can occur as some of the underlying assumptions that were made when building the model are discovered to be less accurate or when new data sources become available.

    New Relic, meanwhile, provides an observability platform that is widely employed by DevOps teams to monitor and observe an IT environment. IT teams that have access to New Relic One can now also view dashboards provided by Mona that detect anomalies involving data integrity issues and model performance issues.

    The integration also enables users to create custom Mona alerts that are shared via the New Relic Alerts and Applied Intelligence service. That capability reduced the volume of alerts generated by correlating anomaly detection to specific IT events.

    Yotam Oren, CEO of Mona, said that level of integration provides a bridge between DevOps and data science teams that typically have widely divergent cultures.

    Incorporating AI models within applications is the next major DevOps challenge. There is almost no application being built today that won’t incorporate some level of AI. The challenge is AI models are built by data scientists that employ a wide range of machine learning operations (MLOps) platforms to construct those models. The pace at which those AI models are developed, deployed and updated varies widely. However, all organizations will eventually need to confront the problem of how to insert AI models within applications both before and after they are deployed in a production environment.

    There are two schools of thought about how best to achieve that goal. The first is to assume an AI model is just another type of software artifact that can be managed as part of an existing DevOps process. In that context, there may be no need for a separate MLOps platform. Conversely, proponents of MLOps contend AI models are built using pipelines created by data engineering teams working in collaboration with data scientists. Developers only become part of the process when an AI model needs to be inserted into an application environment. AI models may ultimately need to be incorporated within an application, but the proponents of MLOps platforms maintain building models requires a unique platform to manage a software artifact that is built by training algorithms.

    It’s only a matter of time before compliance issues force some form of convergence between DevOps and MLOps teams, noted Oren. The longer it takes to address both the cultural and technical issues that are required to meld DevOps and data science teams, the more challenging it will become as both teams are set in their respective ways.

  • Bridging Departmental Divides for Successful Automation Projects

    Bridging Departmental Divides for Successful Automation Projects

    For too long, IT has been largely isolated from an organization’s core business. Any division between IT and lines-of-business (LOB) is even more detrimental when speed is not just a competitive advantage but an existential necessity in today’s accelerating digital economy. 

    As business leaders streamline and turbocharge every facet of their operations, savvy organizations are rushing to eliminate inefficient and damaging gaps between departments by putting more software tools in the hands of more employees. Analysts predict 80% of technology products and services will be built by those who are not technology professionals by trade by 2024. 

    This hits home amidst the booming trend toward robotic process automation (RPA), low-code/no-code and other automated solutions, which have only continued to grow as more businesses realize the vast benefits of automation: Accelerating operations while also reducing costs; elevating customer experiences and shifting employees to higher-value positions and laying the foundation for new data-driven revenue streams.

    Squandering Automation’s Advantages

    But these advantages are quickly squandered if there’s a turf battle between the business unit looking to optimize processes and the IT department responsible for deploying the tools to make that happen.

    When there isn’t collaboration and plenty of trust on both sides, automation initiatives are more prone to disappointments and delays. 

    This may happen if the IT department comes across as too smart for their own good, putting less value on feedback from their LOB colleagues and rushing to implement software with a focus on speed rather than outcomes. On the LOB side, leaders may assume their IT counterparts are too technical and don’t understand business objectives and choose to override important IT input about which vendors are best qualified when it comes to support, integration and security.

    The problem here is not the technology; hundreds of thousands of businesses across the world have successfully deployed process automation solutions. It’s the execution.

    When an automation initiative fails, there’s almost always blame to be shared on both sides of any divide. Likewise, success typically boils down to people across IT and every business department working better together to achieve a common goal. 

    To embrace a collaborative mindset and set up your automation projects for success from day one, I encourage you to follow these clear steps:

    1. Reinforce a shared mission: Whether it’s automating the customer onboarding process or deploying RPA bots to automate a repetitive, time-consuming process, communicating a shared mission is the crucial first step to pulling off a successful project. On the IT side, that involves talking with the LOB about their goals, objectives and business strategy. LOB leaders, meanwhile, can emphasize that IT is an equal business partner that has valuable insights and expertise to contribute.
    1. Establish visibility and transparency: Armed with a full understanding of business objectives, IT leaders can now evaluate tools built to give all stakeholders a full view of the processes that will be affected. By documenting and mapping out each process within an organization, leaders can better understand current processes and gain insight into areas that are ripe for standardization and automation. 
    1. Tailor solutions that match the problem: With heightened visibility across the organization, LOB and IT teams can then determine the scope of each problem and tailor solutions accordingly. Some processes can be kept and optimized; some can be tweaked with automation. Other processes may need to be reconfigured significantly before automating or shut down entirely because they are outdated or unnecessary. 

    A great example of this collaborative approach comes from Coca-Cola Beverages Florida, LLC (Coke Florida): Encumbered with a legacy process repository — a collection of PDFs, videos, pictures and spreadsheets outlining more than 600 processes — Coke Florida standardized and leveraged visual process mapping software to establish an easily accessible document repository that provides visibility and control over key processes, encourages collaboration and increases accountability. 

    Coke Florida continued an organization-wide initiative to digitize and automate its business processes with digital workflows, forms and RPA software, driving further efficiencies across its entire organization. As the company discovered firsthand, shared goals result in shared success. 

    When speed and high-quality outcomes become the norm, companies master the essential arts of urgency, resilience, visibility and collaboration. By bridging the divide between departments, organizations not only drive internal efficiencies but also gain a competitive advantage that is indispensable in today’s burgeoning digital economy. 

  • Techstrong TV: Applications of AI in the Real World

    Techstrong TV: Applications of AI in the Real World

    Alan and Christelle talk about the “hello, Human” podcast series from FortressIQ where they discuss the latest topics in artificial intelligence and how it’s being applied in the real world. The video and a transcript of the conversation are below.

    Intro:  This is Digital Anarchist.

     

    Alan Shimel: Hey, everyone, welcome to another segment here on TechStrong TV. I’ve got a new guest who’s never been on TechStrong TV with us today. Her name is Christelle Flahaux – Flahaux – did I pronounce it right?

     

    Christelle Flahaux: You did, yeah, Flahaux, perfect.

     

    Shimel:                Okay. Hi, Christelle. Welcome.

     

    Flahaux:                Hi, Alan.

     

    Shimel:                Thanks for coming on our show, today. Christelle is the VP marketing over at Fortress, and she is gonna tell us about some – well, she’s gonna tell us about the company, number one, and then we’re gonna talk about some interesting podcasting she’s been doing. Christelle, we haven’t had anyone from Fortress, here, in a long, long time, so it falls on you, I’m afraid, to –

     

    Flahaux:                [Laughs] Give the update.

     

    Shimel:                Yeah, you’re gonna have to – well, before we even do an update, not everyone out here may be familiar. Let’s get’em familiar.

     

    Flahaux:                Sure, yeah, so I have actually been with FortressIQ for about a year-and-a-half, now; company’s been around for about four years. And we are in the business of delivering process intelligence. And what that means is, basically, helping large enterprises, large companies, find all the blind spots in their processes, right? Like, processes, the minute you deploy them, they go awry, right? Whether it’s human intervention, or outdated technologies, and so, we help folks kind of figure out what those processes are, and where there’s the ability for transformation. So, whether that be automation, whether that be retraining employees, process reengineering, but we do it from the human perspective, so we follow the human, not just the log file.

    Because not all processes happen just in Oracle or just in, you know, your ERP system. So, we connect all those pieces together, so we can figure out what the human’s actually doing.

     

    Shimel:                Love it. Love it, love it, love it. All right, and as we mentioned, you are CMO, there?

     

    Flahaux:                yes, correct.

     

    Shimel:                And you have been doing some podcasts – well, let me not put words in your mouth.

     

    Flahaux:                [Laughs] Well, so, yeah, so –

     

    Shimel:                What have you been up to, lately?

     

    Flahaux:                What have we been doing. Yeah, so when I started, you know, one of the things, because the company was so new and it’s a relatively new space, that is adjacent to a very hot automation space, right? Like, everyone’s heard of automation anywhere, UI path. So my big challenge was just getting the brand out there, right? Letting people understand what FortressIQ was about. And the other thing, too, was just education around artificial intelligence. I mean, I’ve been in tech for most of my career, but I think, you know, this new wave of artificial intelligence, computer vision, machine learning, I think a lot of people, especially over the age of 40, are afraid, right? Like, “Well, what is AI gonna do? Is it gonna replace my job? Is – ”

     

    Shimel:                Skynet.

     

    Flahaux:                Yeah, exactly, Skynet, Terminator, you know, the Borg, right? Like, what is this actually gonna do? And the whole concept of the brand came from, humans and technology are supposed to work together. And they can work together to take away all of those menial tasks, and all those things that get people down and, you know, that are mundane, and let the humans actually use their brains, right? Like what we’re supposed to be, and be the creators and be the innovators, and not getting bogged down in the tasks. So, it really was around creating this brand affinity to a company that’s gonna help you get comfortable with AI, right? And it was Covid, right? I joined the company middle of Covid, and podcasts seemed like a normal thing, right?

    We didn’t have events, anymore, we needed to get the brand out there in a way that would resonate, and so, we created this podcast with the idea of educating people around how AI is actually being used in everyday life, and how AI is being used for good. So that’s why we started it.

     

    Shimel:                Excellent. You know, I will tell you, not that I’m over 40 – well, I am, but – you know, AI’s gotten a bad rap, right? I think there is the Skynet Terminator people; there are other people who thin AI is like Steven Spielberg’s kid in the movie, you know, the AI movie. And, you know, maybe one day, but that’s not the AI that you’re talking about, that’s not the AI that we deal with a lot in our tech worlds. Most of the AI we do is a lot of machine learning, and then applying what we learned or from what patterns we see, and applying some intelligence to that.

     

    Flahaux:                Yeah, totally, totally agree, yeah. And that’s, I think, you know, digital transformation, everybody talks about it and, you know, people are going at it very different ways, and a lot of it’s failing, right? I think there was a stat out by McKenzie, you know, 80 to 90 percent of transformation projects fail, because I do think people aren’t looking at it as a big data problem, right? And big data, that’s where you start talking about the machine learning and everything, that it would take humans just years to go do versus a machine can be trained to go do it in weeks or even days. So, I think that’s the crux of it is people want to transform and they wanna embrace, you know, being digital. But, you know, this big data problem and how to attack it, you need things like machine learning and AI to go get it done.

     

    Shimel:                I agree, I agree with you. You know, I was at a KubeCon in LA, last week, Cloud Native Con, whatever you wanna call it, it’s the first conference I went to [crosstalk].

     

    Flahaux:                How was it?

     

    Shimel:                It was good. You know, the Linux Foundation did an amazing job of trying to make you feel safe. You had to have a vaccine to get in, right? No kidding, no BSing, if you didn’t have proof of vaccination, you did not get in. And then, once you were in, I felt like they made the space three times larger than it would’ve been normally, ’cause whether it’s the keynote room or the expo hall floor, everything was really spread out, really spread out. And you had to wear a mask inside. All. Everywhere. You didn’t wear a mask, security came over and said, “Put a mask on or leave.” And, you know, honestly, I thought they did the best they could do, and it was semi-safe.

    But the important thing was, the big buzzword, there, I mean, there had to be 80 vendors, there, you know, they have a lot of vendors. A lot of observability vendors, as they call themselves now. And really, observability is a big data machine learning kind of issue, right? Because observability doesn’t really get good until you have enough data to learn from, to see patterns, you know, to understand what the heck’s going on. And it just reminded me, again, that, really, at the end of the day, it’s always about the data, right? We’re seeing it in security, for instance, people who are getting wise say, “We gotta secure the data. We’ve been securing the applications, we’ve been securing the endpoint, we’ve been – we gotta secure the data.”

    Our data – who told me – one of the interviews I did, out there, the amount of data that’s generated daily, like, you know, petaflops or whatever, it’s just [crosstalk].

     

    Flahaux:                It’s insanity, yeah.

     

    Shimel:                Yeah, so without some AI machine learning, some – you know, and then, like, okay, this is data that’s near and dear, and we need to keep it in a very high premium kind of storage area. Other data, we need to do our analysis and we could offload that data to somewhere that’s cheaper. Other data, we can analyze and we don’t necessarily have to keep it. Who makes those decisions, right? How do we make those decisions? All of these things kind of go in there and it’s a crazy world, you know, it’s just – it’s not that it’s crazy. It’s a changing dynamic that we’ve gotta learn to manage and make actionable intelligence out of. ‘Cause at the end of the day, that’s what AI’s about, right? Analysis and taking action.

     

    Flahaux:                Yup, and making the decision. I always remember, so, I spent two, almost three years at MAPAR .

     

    Shimel:                Mm-hmm, sure, I remember that.

     

    Flahaux:                Yep, _____ _____ and lots of data scientists, right, on staff. And, you know, we had a database issue from a marketing perspective, and I wanted to clean out – talk about, like, a very small problem, right? – clean out a bunch of old contacts, ’cause I was, you know, they weren’t responding, it was old, and I didn’t wanna, you know, be on a blacklist. And I remember the head data science was, like, “But we have to save all that data.” And I’m, like, “No, we don’t, ’cause it’s changed,” right, half these people probably –

     

    Shimel:                It’s useless.

     

    Flahaux:                Yeah, it’s useless, like, they’re at a different company now, and it’s a wrong e-mail address, wrong address, and – and it was just this argument, right, kind of this philosophical argument about, “You have to keep the data.” [Laughs]

     

    Shimel:                [Crosstalk] it’s sacrosanct, right, like, it came down from the word of God and it should’ve been included in the Bible, you know, and – but, no, it didn’t, it wasn’t included in the Bible for a reason. It’s not, you know, it’s not the US constitution, either. We can get rid of it. These are people who’ve moved on from their jobs and those e-mail addresses don’t work, anymore.

     

    Flahaux:                Yeah.

     

    Shimel:                But let’s talk a little bit about running – is this the first time you’ve kind of hosted a podcast and got that all up and running?

     

    Flahaux:                Yes, no, it is the first time that we’ve started a podcast. I do remember, back in the early days, though, when I was at Arriba, and we had talked about starting a spend management podcast. And we did, and I don’t think it was very successful, I mean, I don’t think podcasts were that exciting, back then, or people were adopting it. But we actually sent out, you know, actual, you know, the old iPods.

     

    Shimel:                [Crosstalk], yeah, yeah, [crosstalk] people to listen.

     

    Flahaux:                The old iPods, and we loaded it with a bunch of episodes and, you know, engraved the back of the iPod. So, I still remember that campaign.

     

    Shimel:                And a little expensive to do that, kind of defeats the purpose.

     

    Flahaux:                Yeah, well, Arriba had deep pockets, back then, so it was okay for them to –

     

    Shimel:                I remember those days, Arriba – who was the flipside of Arriba _____ – yeah, crazy times [crosstalk] dot-coms.

     

    Flahaux:                Yeah, yeah, they’ve done well.

     

    Shimel:                Yeah, no, they have. Let’s talk about, like, how do you determine guests and stuff for your podcasts?

     

    Flahaux:                Yeah, so, you know, we didn’t think this was going to be a big podcast, right? We set out with a goal of having maybe 1,000 listeners, right, like, to start. And so, when we did the first initial list of who we wanted to go after, it was just people in our networks, right? Like, I know Kamal at Eightfold AI who’s doing some really great stuff with HR and talent management, and applying AI to it. You know, the podcast host, John, had a couple of friends, you know, that he knew that were in this space, from his time at the DoD, and obviously, _____, our CEO, was one of’em.

    So it was kind of a small list to start with, and we finished the first season and I looked at everybody who was on the first season and I was, like, “Wow, we have no women. None of these people on here are females.”

     

    Shimel:                [Crosstalk], yeah.

     

    Flahaux:                And it’s not like we did it on purpose, right? Like, we literally [crosstalk].

     

    Shimel:                No, quite the contrary, it’s on purpose, almost, that you have to go get women or other underrepresented communities. I mean, I run into it, frankly, all the time on our video shows, right? [Crosstalk]

     

    Flahaux:                Yeah, until you make it a priority and – so we wanted to do something for March, for International Day of the Woman, and I had an intern, who actually converted to a fulltime employee, and she’s passionate about this stuff. And so I just told her, I said, “Look, I wanna get four women, for March, right, like, you know, quick little month-long miniseries. Go get us four women.” And we ended up getting eight. People wanted to do it. And that’s the thing, from a podcast perspective, I’m sure you know this, if you ask, people are often [crosstalk].

     

    Shimel:                There are plenty of people out there, oh, absolutely. You gotta know who to ask is the issue, right? We, you know, we do – so we do a series of – besides this TechStrong TV kind of interview like this, we do 45-minute kind of longform video where we dive in, right, there’s Dev Ops Unbound, CISO Talk, the SRE Show, very nerdy geeky stuff, but it’s who our audience is and what we’re into. And our biggest thing is, once we identify someone, they almost always will do it. It’s just identifying. Go find me some women who talk about SRE stuff, right? Go find me some female CISOs. Well, there actually are a decent amount of female CISOs, now, that you can go to, but, you know, some of the other stuff, female QA testing and stuff like that, you know, it’s hard. It’s constantly a challenge for us.

     

    Flahaux:                Yeah, it’s hard, and I think now that, you know, we identified that we didn’t do it the first season, and we did this little miniseries and, you know, now I think, when we planned for this next season that just launched last week, it was, you know, “Let’s go cast a wider net and see what we get, and then prioritize.” We put on the show and we can always record and, you know, if we end up having – there’s no rules in podcasting, right, like, how many episodes need to be in a series, right, or how often you do it. And I think that’s the biggest lesson learned is there are no rules to this, right? So just generate content and get it out there and see how people consume it.

     

    Shimel:                Yeah, I try to do them on a consistent basis. Like, our cadence for a lot of the longform video – ’cause we do more video than audio, now, right, [crosstalk].

     

    Flahaux:                Okay, yeah.

     

    Shimel:                And we try to do every-other-week, right, I think that’s a good cadence. I mean, think about how you stream TV, like, you know, this is perfect. When streaming TV first came out, you could binge the whole season in a weekend, right, Netflix and chill. And now, most of the streaming channels don’t do that, they don’t let you do that, right?

     

    Flahaux:                No.

     

    Shimel:                They release a new episode every Friday [crosstalk] back to when we were one network TV and, you know, Happy Days was Thursday night, or whenever that was.

     

    Flahaux:                Yeah, and TGIF, right, you sat in front of the TV or – you know.

     

    Shimel:                Right, because you knew that was it. We’re almost coming back to that, I think. People, I don’t know if it’s a Covid thing, but people want that kind of regularity.

     

    Flahaux:                It’s something to look forward to.

     

    Shimel:                Yeah. Well, that’s totally right, you can schedule around, it’s not, “What do you wanna do?” “Oh, let’s just binge out, you know, and watch 20 episodes of this.”

     

    Flahaux:                Yeah.

     

    Shimel:                Anyway, _____ I wish you a ton of luck with this.

     

    Flahaux:                Thank you.

     

    Shimel:                It’s always good to see more podcast folks out there. Maybe this is something we could get – you know, we’re doing more and more distribution through TechStrong TV, so, that would be a pretty cool thing –

     

    Flahaux:                Yeah, no, I think that would be great.

     

    Shimel:                – we can talk.

     

    Flahaux:                Yeah, no, that sounds awesome.

     

    Shimel:                Well, welcome to the ranks, and continued success with it.

     

    Flahaux:                Thank you. Yeah.

     

    Shimel:                More importantly is, well, success with FortressIQ, right, it’s important stuff.

     

    Flahaux:                Yeah, it is, it’s fun, it’s definitely an exciting space to be in, so.

     

    Shimel:                Very cool. Alrighty – oh, wait, we didn’t tell people, where do they go listen to the podcast?

     

    Flahaux:                You can go to fortressiq.com/hellohuman, you can find us there, all of our episodes are up there. And if anybody watching wants to be on it as an AI and has an opinion, find me on LinkedIn, Christelle Flahaux, or on Twitter @mktgstella, marketing Stella, and we’ll get you on the show.

     

    Shimel:                Love it. Thank you, Christelle.

     

    Flahaux:                Thanks, Alan, I appreciate it.

     

    Shimel:                Alrighty. Hey, we’re gonna take a break, here, on TechStrong TV. We’ll be right back with another guest.

     

    [End of Audio]

  • Say Goodbye to Late-Night SRE Wake-Up Calls

    Say Goodbye to Late-Night SRE Wake-Up Calls

    Thousands of SREs, on-call engineers and DevOps pros all over the world dread nothing more than the late-night incident alert. The pager buzzing at 2:00 a.m. can cause panic for SREs and leave IT and DevOps teams with quite a mess to contain. But incident response doesn’t have to cause panic if you have the right automation tools in place. If you have ever wondered why companies like Amazon, Google and Zoom rarely suffer service outages and downtime while other companies struggle to achieve similar efficiencies, you’re not alone. In fact, you’re halfway to understanding what makes incident response automation such a vital component of your workflow. 

    Without a doubt, the best way to take back control over manual incident response and—once again—sleep through the night is to implement a powerful automation solution for incident response. We’ve listened to stories from SREs around the globe about the benefits of automated incident response. Plus, we’ve experienced them ourselves (from companies like Cisco, for example).  In the end, we’ve learned a thing or two about creating efficiency by leveraging automation and integration. Below, we’ll briefly cover how leveraging automation to remediate issues with or without a human in the loop is the best way to say goodbye to 2:00 a.m. wake-up calls.

    An Overview of Incident Response

    First, a staggering fact: In 2019, 17% of global enterprises lost more than $5 million every hour their servers were down, according to Statista. Even for smaller companies, the cost of servers going down is enormous. Following the news of Facebook’s recent outage (losing $13.3 million an hour; not counting the loss from the stock price drop), the need for minimizing downtime and reducing these costs is clear. 

    In order to fix issues faster, organizations need an easy-to-use tool that SREs and DevOps teams can implement to troubleshoot and automate incident response. For one, users should opt for a drag-and-drop system. This method is preferred over headless automation tools that too often result in data loss and extended downtimes.

    Next, IT organizations need to take the next step with automation and implement best practices. We can go from asking “How do we bring in automation?” and start to think in terms of “What are the use cases when I do?” A winning incident response toolset will help customers navigate this challenge. An automation platform should also allow users to fine-tune workflows with a library of connectors and actions that are comprehensive enough to get the job done. Ideally, your cloud stack should include several functions such as alerting (such as PagerDuty), monitoring (like Datadog) and analytics (Splunk, for example), while integrating with collaboration tools like Slack and Jira.

    What Are Some Typical Use Cases?

    Let’s dive deeper into three use cases that incident responders and engineers commonly encounter. These examples demonstrate why a powerful automated platform lets small businesses automate effectively and ensure long-term uptime just like larger enterprises.

    Incident Response Automation

    It’s all hands on deck when that 2:00 a.m. incident response alert goes off. Why rely on manual responses which can often lead to broken uptime SLAs and even drag down a company’s reputation? Automation is the key to operating any large-scale service in the cloud.

    Cost Management

    The costs of extended periods of downtime don’t stop at the checkbook. When incidents occur without drag-and-drop automation, long-term side effects can dramatically up the company’s losses.

    Orchestration

    Orchestrated automation tools provide credential management, templates, playbooks and data processing for any company size. They empower users to curate services to their liking as well.

    Want to Learn More about Automated Incident Response? 

    Sign up for this upcoming devopsy.kinsta.cloud webinar on Monday, October 25th at 3:oo p.m. Eastern. We hope you’ll join us to learn more about how to integrate automation into your workflow and stop those pesky 2:00 a.m. wake-up calls.

  • BMC Acquires StreamWeaver to Advance AIOps Strategy

    BMC Acquires StreamWeaver to Advance AIOps Strategy

    BMC has acquired StreamWeaver, a provider of a platform that makes it simpler to capture streaming data in real-time, as part of an effort to extend the BMC Helix IT operations platform infused with artificial intelligence (AIOps). Financial terms of the transaction were not disclosed.

    Margaret Lee, general manager and senior vice president for digital service and operations management for BMC, said StreamWeaver brings with it a wide range of integrations with multiple data sources that BMC will use to both train AI models and improve overall observability. While connecting to data sources is relatively straightforward, the challenge now is collecting that data in real-time in a way that is easily repeatable for IT operations teams, noted Lee.

    In general, AIOps continues to gain traction as IT environments become increasingly complex. Most IT operations teams are not going to be able to manage highly distributed computing environments without augmenting their IT staff with some AI, said Lee.

    Naturally, many rote tasks that were once performed manually by IT operations professionals will become increasingly automated. However, there will always be a need for IT personnel, noted Lee.

    Arguably, there may come a day when IT professionals will not want to work for organizations that don’t have an AIOps platform in place simply because the tasks assigned to them would otherwise be considered archaic, especially if they involve a series of tedious tasks that not many IT professionals really want to perform.

    At the same time, AIOps should reduce overall risk by making it easier for IT operations teams to proactively identify issues before they disrupt an application service. That’s especially critical as IT environments—increasingly with microservices-based applications constructed using containers—and serverless computing frameworks are being deployed with greater frequency alongside legacy monolithic applications.

    BMC has been making a case for AIOps as far back as 2017. However, since then, a wave of startups and IT operations incumbents have either built an AIOps platform from the ground up or updated an existing platform with AI capabilities. It’s difficult to assess which vendors are now ahead in terms of the AIOps race, but one thing that is certain is that IT organizations now have plenty of options.

    From a cultural perspective, however, not every organization is entirely comfortable with AIOps. While some IT professionals remain skeptical, others view AI as an existential threat to their existence. Most IT teams are also concerned about the potential impact any flawed AI model might have on IT operations—it’s one thing for a human to make a mistake, but an AI model making a mistake at scale could be catastrophic.

    There are few IT organizations that are embracing AIOps across the board, but most do recognize that AIOps platforms, in one form or another, are inevitably here to stay. After all, machine learning algorithms never forget anything they learn. Nor do they ever take a day off or decide to leave when offered higher pay. The challenge is figuring out exactly where the interface between IT staff and algorithms is going to be—not just today, but also in the near future.

  • Red Hat Extends Scope of Ansible Automation Ambitions

    Red Hat Extends Scope of Ansible Automation Ambitions

    During the online Ansiblefest, Red Hat announced the availability of a preview edition of Red Hat Ansible Automation Platform 2 that is intended to make it easier to automate IT processes at scale.

    Richard Henshall, senior manager for Ansible product management at Red Hat, said previously most IT teams have been automating individual processes, but as organizations become more adept at creating playbooks to automate processes, they now need to find ways to manage multiple automations that are often dependent on one another.

    Ansible Automation Platform 2 also enables IT teams to automate processes that span both monolithic as well as cloud-native applications based on containers using an automation controller, formerly known as Ansible Tower, that is more tightly integrated with Red Hat OpenShift, an application development and deployment platform based on Kubernetes, using Red Hat Operator tools. There is also an automation mesh capability that connects disparate automation components together and provides status checks.

    Ansible Automation Platform 2 also introduces automation execution environments within Ansible Engine that make it possible to create self-contained automation spaces that can be easily replicated and repeated across an organization.

    Red Hat also includes an automation content navigator to helps teams validate that automation content is working as it should across even the largest environments, along with updates to the Red Hat Insights analytics service that enable issues that might occur with automation controllers to be surfaced and eliminated by automatically applying policies.

    Henshall said going forward, IT teams should expect to see Red Hat focus more on enabling events to be the catalyst for triggering automation. Today, most automated processes begin with an IT administrator triggering the process. However, as digital business transformation initiatives mature, it’s become apparent there will be a need to trigger automation when specific events occur.

    Henshall said while there are still many organizations that are just starting to automate IT processes, there are also many that are entering the next phase of maturity. As such, they now require an automation platform that makes it simpler to manage automation at scale.

    In general, Ansible is designed to make it possible for developers and IT operations teams alike to declaratively create automation without much programming expertise required. However, creating a playbook that works reliably still requires a deep understanding of the processes that are being automated. Most IT teams would be well advised to closely monitor processes when they are first automated to make sure they are performing tasks as anticipated.

    Ultimately, it’s now a question of when rather than if most IT processes will be automated. DevOps teams, of course, have always been at the forefront of automation, but now it’s clear that as IT environments become more complex—with the rise of both the cloud and edge computing platforms—enterprise IT teams need to embrace automation more aggressively. The biggest barrier to automation is simply finding someone who has the passion to automate a process to lead the charge, said Henshall.

    Naturally, most of those efforts will initially focus on repetitive, tedious and manual IT tasks, but the potential to automate IT processes at levels of unprecedented scale has never been greater.

  • How Quantum Computing can Solve Real-World Problems

    How Quantum Computing can Solve Real-World Problems

    The history of technology can seem like it was very predictable in retrospect, but the future typically feels more uncertain. Nowhere is this uncertainty more evident than in the domain of quantum computing. When the spectrum of possible outcomes spans from “quantum computers will be one of the most important technology developments of all time” to “quantum computing may never really become practical enough to justify using over a classical computer alternative,” trying to make forecasts can seem futile. However, as a technologist, investor, consumer or just a curious observer, the boundaries and texture of the uncertainty itself can be very interesting, valuable and informative. 

    Quantum computing isn’t likely a replacement for today’s classical computing—at least not initially—but rather a potential complement to it for specific applications. A 2021 report by Deloitte lists dozens of applications that could be transformed by quantum computing approaches: Protein folding, fluid simulation, credit underwriting, financial risk analysis, supply chain optimization and forecasting, vehicle routing, fraud detection, fault analysis, weather forecasting, semiconductor chip design, product-portfolio optimization, consumer product recommendations—and this is only half the list. 

    Quantum computing could make previously intractable simulation, search and optimization calculations relatively easy and quick. For some kinds of calculations, a quantum computer could be mind-bendingly faster than a powerful classical computer could ever be. While today’s classical computers running machine learning systems can make incredibly accurate predictions, quantum-based systems can, in theory, far outstrip their speed at certain prediction-related tasks.

    The blend of physics, math and computer science behind quantum computers is fascinating, but complex. Computer scientist Scott Aaronson, one of the best science communicators, wrote a recent essay for Quanta magazine called, “Why Is Quantum Computing So Hard To Explain?” 

    To oversimplify, quantum computers are built around “qubits,” which are subatomic-scale components, often kept at incredibly cold temperatures (think: Absolute zero) to minimize interference from the rest of the universe. These components can be put into a quantum physics state called “superposition” that allows them to, in a sense, take on many potential values at once. Even though their value is uncertain, reliable calculations and transformations can be performed on these qubits while in a superposition before being reduced to a more classical state, effectively parallelizing computations. Qubits in a quantum computer can also be entangled with one another (a phenomenon that Einstein referred to as “spooky action at a distance”), harnessing them as a team to increase the variety of logical calculations that it’s possible to compute. For certain types of math—for example, searching for an optimal outcome from myriad options—quantum algorithms can seem close to instantaneous when compared to those that run on classical computing hardware. 

    Quantum Computing Challenges

    Publicly available quantum computing has been on the horizon for decades, yet there’s still no reliable forecast for when products capable of widespread adoption will get released, exactly what form the systems will take or how broad and deep quantum computing’s impact will be. There are many technical challenges when it comes to getting a broadly applicable quantum computer to be useful at scale. And quantum computers are racing against classical computers, which have also been improving very rapidly in power, versatility and ease-of-use. 

    One important bottleneck for quantum computers is that correctly reading the results of a quantum calculation is prone to a very high error rate—the delicate superposition state can deteriorate before the correct result is presented as an output.

    Aaronson explains it:

    The problem, in a word, is decoherence, which means unwanted interaction between a quantum computer and its environment — nearby electric fields, warm objects, and other things that can record information about the qubits … The only known solution to this problem is quantum error correction… But researchers are only now starting to make such error correction work in the real world. When you read about the latest experiment with 50 or 60 physical qubits, it’s important to understand that the qubits aren’t error-corrected. Until they are, we don’t expect to be able to scale beyond a few hundred qubits.

    Some theorists even believe a practical quantum computer is impossible to build because of the inherently high amount of “noise in the system.” Mathematician Gil Kalai predicts that doing error correction to reduce that noise to a usable level would, by basic computing theorems, restrict the computer’s number-crunching capacity so low as to be not worth using.

    Nevertheless, researchers continue to chisel away at the challenge of error correction and to pass key technical milestones. For example, in July, Google researchers published a paper in Nature explaining how they have found a promising error-reduction method that scales as more qubits are added to a system. 

    Hardware, Software and App Landscape

    There are several different approaches to quantum hardware. Rigetti and Oxford Quantum Circuits use superconducting quantum circuits, a more widespread approach favored also by Google, Microsoft, and IBM. IonQ (which is planning to go public via a SPAC transaction) and Honeywell (which recently announced a combination of its quantum computing unit with UK-based Cambridge Quantum Computing) use trapped ions. D-Wave uses quantum annealing, ColdQuanta is using cold atoms and Xanadu is using photonics. Each approach has its pros and cons, and each hardware technology faces a fluid set of shifting bottlenecks in reaching affordable scale. Work at the materials layer continues to advance as well, for example, Raicol Crystals is growing quantum quasi-phase matching crystals that can be used in applications as varied as quantum computing, sensing, encryption and communications. And it’s not certain that there won’t be another approach that leapfrogs them in solving the challenges of error correction and price.

    Other companies, such as Quantum Machines, Q-CTRL and Seeqc, are building control hardware that can operate in the space between classical and quantum hardware. Control systems can exist at temperatures warmer than absolute zero, but colder than room temperature. Some of these systems involve both software and hardware and can perform tasks like monitoring the quantum processor’s performance, performing error correction or serving as an abstraction layer connecting classical and quantum hardware. 

    There are also companies creating quantum computing application layer software, like Zapata Computing, Riverlane or QC Ware. This can include application frameworks, components, algorithms or even turnkey quantum computing applications. Classiq has software for quantum circuit synthesis. There’s also a lot of interesting fundamental research happening at the software intersection between quantum computing and artificial intelligence – e.g. Zapata published work recently using IonQ’s ion trap quantum system to train a machine learning system to generate high-quality handwritten digits with low error rates. 

    One of the first theoretical uses for quantum computing, proposed in 1994 by mathematician Peter Shor, would be to crack the RSA encryption widely used today to protect data. The threat spawned research into post-quantum cryptography, with researchers proposing multiple new approaches to encryption that would need to replace today’s algorithms to preserve the privacy of data. Companies such as ISARA (quantum-resistant encryption) and Quantum Xchange (an out-of-band, symmetric key delivery platform) emerged to help prepare governments and companies now for a world where quantum-based, encryption-cracking algorithms start to work on breaking today’s encryption.  

    There are several widely used software development kits (SDKs) that let developers write software for a quantum computer without actually having one to run it on. In fact, a kind of format war has already broken out between quantum computing development environments.

    One widely-used quantum SDK is IBM QISKit, an open-source Python-based development kit for prototyping software and devices on simulators or IBM Quantum Experience, a cloud-based quantum service. ExxonMobil, Goldman Sachs, Boeing, JP Morgan, Samsung and PayPal are just a few of IBM Quantum’s marquee customers. Google Cirq, another Python-based development kit, touts Volkswagen as a user, and Volkswagen is also a contributor to Google’s TensorFlow Quantum, an open source library that extends Google’s TensorFlow machine learning algorithms to quantum processors for rapid prototyping. Microsoft’s Quantum Development Kit (QDK) is based on Microsoft’s Q# programming language and brings quantum compatibility to Microsoft Azure cloud services. Early customers of Azure Quantum include Dow for chemical simulations and Toyota Tsusho, Toyota’s trading arm, developing traffic light optimizations to reduce urban traffic congestion.

    In a recent piece, The Information noted that “Amazon is looking to hire more than 100 new quantum computing scientists, hardware developers and engineers within its Amazon Web Services cloud business,” following the enormous amount of funding flowing to startups in the space, such as Quantum Motion, Atom Computing and PsiQuantum. Amazon also launched Amazon Braket, a fully managed quantum computing service that gives customers access to hardware from a diverse set of vendors such as IonQ, Rigetti and D-Wave. 

    It’s also possible that the most valuable quantum platforms won’t be versatile, horizontal platforms at all; rather, the space could evolve instead to include special-purpose machines, or quantum application-specific integrated circuits (ASICs). Unlike the way things have played out with classical computing, this could mean that quantum computers would be highly specialized integrated hardware and software machines tailored to specific applications, e.g. fluid simulation or fraud detection. 

    Early use cases may involve quantum systems taking specialized roles as part of a larger classical system, similar to how NVIDIA’s graphics processing units (GPUs), which often run alongside an advanced CPU, can be used to offload specific computations for which the GPU is well-suited. In this model, where quantum components are an “accelerator” to classical systems, a credit underwriter might use a quantum processor to handle one of the tasks involved in scoring applicants and might use a different special-purpose quantum processor to perform a piece of a calculation to optimize its borrower portfolio. 

    For many use cases, the error rates of calculations are still too high for developers to do more than hone their coding chops on quantum simulation platforms, waiting until quantum computers start to really work at scale. Quantum simulators, such as QMware, make quantum software algorithms and applications believe they are running on actual quantum hardware, but they are really running on classical computers pretending to be quantum computers. 

    In the meantime, to manage some of the timing uncertainty, quantum-related startups can pursue profitable projects with government, corporate and university buyers today as a source of funding and requirements. Like some biotech startups, they can do this while assembling a strong team and seeking an early adopter clientele, progressing through scientific milestones while keeping an eye on future commercial markets.  

    The hurdles to generally available quantum computers are much like those faced by alternative energy sources: Unlocking the potential will require breakthroughs in hardware design, lower manufacturing costs and a driving force to spur large-scale adoption. And many approaches won’t work. 

    And as with any technology, it is, of course, possible that software developers will find valuable applications for quantum processors that people haven’t thought of yet today—just as developers found that GPUs meant to handle graphics processing also excel at training highly parallelized machine learning models.

    That said, a broadly useful and effective quantum computer’s arrival has the potential to be as disruptive an opportunity as the creation of the Internet or the use of machine learning to make predictions. 

  • Dell Updates AIOps Platform to Better Automate IT Ops

    Dell Updates AIOps Platform to Better Automate IT Ops

    Dell Technologies this week updated its IT operations platform infused with artificial intelligence, dubbed CloudIQ, to add support for its PowerEdge servers. In addition, Dell pledged to add support for its PowerSwitch networking hardware next month as part of an ongoing effort to extend the reach of its AIOps platform across the entire Dell EMC portfolio.

    At the same time, Dell next month also plans to employ webhooks and a REST application programming interface (API) to both integrate the CloudIQ cloud service with third-party platforms and share notifications and recommended actions via tools and platforms such as ServiceNow, Slack, Microsoft Teams, Ansible and vRealize.

    Dell has also defined an autonomous operations framework that defines the various stages of AIOps capabilities that organizations should be able to take advantage of as CloudIQ continues to evolve.

    Dell AIOps

    Drew Schulke, vice president of product management for Dell Technologies, said CloudIQ currently enables IT organizations to achieve level three of that framework. As Dell continues to update CloudIQ alongside delivering ongoing infrastructure upgrades, additional capabilities will be steadily added, noted Schulke.

    Dell is making a case for standardizing on both its infrastructure and the IT operations platform it provides. Whether acquired and managed by an internal IT team or consumed as-a-service provided by Dell, the goal is to convince IT teams to reduce their reliance on rival infrastructure platforms that are not as tightly integrated with CloudIQ. In effect, Dell is delivering continuous intelligence as an AIOps service, said Schulke.

    Of course, IT operations teams could opt to standardize on an AIOps platform that is integrated with infrastructure provided by multiple vendors. However, Dell is betting that an AIOps framework optimized for its platforms will reduce the total cost of IT in a way that IT organizations will not be able to ignore.

    Each IT organization will need to decide for themselves what path forward makes the most sense for them. However, as more AI capabilities are infused into IT operations platforms, it’s becoming clear that many of the tasks routinely performed by IT teams are becoming increasingly automated. Most organizations will need to make a decision in the months ahead about the degree to which they are comfortable waiting for their existing IT operations platform to be enhanced with AI capabilities versus acquiring a new one that might be more advanced.

    Regardless of the path forward, the level of cultural disruption AIOps will bring to IT teams will be high. DevOps teams, naturally, have always been at the forefront of IT automation. However, most of the recent advances in IT operations have generally been applied in a piecemeal fashion. Platforms such as CloudIQ are designed to be implemented on a more end-to-end basis.

    Thate level of automation will have a profound impact on everything from the number of applications an IT team can support to the roles of the individuals that make up that team. It’s not likely that AIOps will replace the need for those IT teams as much as augment them and redefines the job they are being asked to perform.

  • Is AI Taking Over DevOps Functions?

    Is AI Taking Over DevOps Functions?

    Artificial intelligence has taken the tech world to a new level of automation. Today, almost every specialization demands the intervention of machine learning to develop AI technologies that help businesses do more with less time and resources. Still, some organizations question whether leading with AI is a good investment. 

    For DevOps, the answer is a resounding yes. AI can enhance DevOps practices to accelerate the pace of software releases, helping businesses achieve continuous delivery. This enables programmers to release software about 10 times faster and allows programs to be reviewed before they are released. 

    AI also has improved DevOps culture, from enabling more efficient decision-making processes to code quality enhancements and automated operations. So, let’s take a deeper dive into how AI impacts DevOps.

    Recent Changes in DevOps

    Monitoring and managing all the data generated in DevOps environments involves a high degree of complexity, making it difficult for teams to collect and use data effectively. In addition, the volume of data any given team may receive can reach well into exabytes, so AI tools provide much-needed assistance. After all, analyzing massive data sets manually would take too much time for a human and won’t meet the demands of modern businesses.  

    What’s more, surveys show that 57% of developers in the United States have less than five years of experience. For this reason, software testing must be an ongoing and in-depth process to check and double-check that no vulnerabilities impact the security of the code. AI can supplement manual review to increase speed and accuracy in finding bugs. 

    That being said, integrating AI into DevOps functions doesn’t mean developers aren’t necessary, even though their roles have evolved considerably. Backend developers are involved in the development and operations sides as they take on ops tasks and tests, especially around cloud-based infrastructure and cybersecurity. And frontend developers will always be needed for the technical support of creative design—which no one can do better than humans. 

    In today’s dynamic and fast-paced world, developers need to release code faster than they used to while the operations teams ensure that the existing systems function with minimal disruption. This partnership is easier when integrating AI, as it makes the collaboration between development and operations teams more efficient. AI-powered systems provide a unified view into systems and glitches in the complex chain of DevOps. 

    Is AI Taking Over DevOps?

    Short answer: No. AI is supplementing human activity in DevOps to make things more efficient and secure. 

    Due to the complexity of DevOps requirements, people have been looking for a more automated solution that could assist humans in performance and accelerate the processes. What’s more, you can expect to pay around $60 an hour for an experienced backend developer in the U.S. This means using AI to automate the grunt work can be a big cost saver as well.

    Here are a few ways AI transforms DevOps functions:

    Enhanced Security

    Distributed denial of service (DDoS) and related attacks have become a widespread threat to the security of websites and online services these days. AI-powered tools have the ability to identify and mitigate these threats. In addition, AI can help in the pivot to DevSecOps in teams still using traditional DevOps.

    AI security tools detect anomalies and threats based on real-time data and by analyzing past behavior. In this way, AI has played a vital role in protecting many organizations, including schools and colleges, from cyberattacks by supplementing human security experts.

    Improved Data Access

    The massive amount of data that needs to be collected, organized and analyzed in DevOps is beyond human capabilities. However, AI has resolved this issue by compiling data from multiple sources and organizing it for analysis. This drastically improves and accelerates the process of DevOps.

    Rapid Software Testing

    Software development and software testing has accelerated with the integration of AI. As a result, various testing types used by DevOps, such as user acceptance testing, regression testing, and functional testing, are more efficient and accurate than ever.

    These tests produce a large amount of data that would take humans ages to identify and collect manually. With the help of AI, identifying patterns and coding practices that lead to errors and vulnerabilities has become convenient and fast. This data can then be used later by the DevOps team to increase their efficiency and improve development practices. 

    Timely Alerts

    DevOps teams sometimes struggle to react and respond to the alerts during incident response. With no priority tags attached, it becomes challenging for the team to prioritize incidents effectively. A more efficient, comprehensive alert system should be capable of spotting flaws instantly and marking the more severe ones as higher priority. That way, the team can tackle the issues more systematically and resolve them without failure.

    AI can assist in prioritizing the responses to alerts based on certain factors, including the intensity of the alert, the source of the alerts and past behavior. This leads to efficient management in situations where systems get flooded with massive amounts of data and have to respond immediately. AI-powered alerts are particularly important in DevOps security, so this is a critical benefit of AI in the discipline. 

    Superior Implementation Efficiency

    DevOps teams are often burdened by the managerial tasks of a rule-based environment which decreases their time spent in more innovative and creative areas. When AI takes over, these tasks become self-governed, increasing efficiency and reducing human intervention. AI systems can work on their own, sparing humans from these tasks to focus more on innovation and creativity.

    This way, AI has turned the DevOps into self-governed systems that no longer require the rule-based, human management of analysis. This should resolve the complexity of research that DevOps teams were struggling to achieve and enable faster adaptation.

    Feedback Loops

    The primary function of DevOps is to use monitoring tools to gather feedback from every stage of operations and then use that to improve software development and delivery processes. Performance monitoring tools use machine learning to gather information such as performance matrices, log files, datasheets, etc. The feedback collected is then used to track potential issues in advance and make suggestions to resolve them accordingly. The application is then altered by applying these suggestions to make it more efficient.

    Artificial intelligence is driving increased efficiency in DevOps functions. However, it would be a stretch to say that it is taking over, as there are still many areas that require human intervention. The idea behind AI integration is not to change the players but to change the game.

    Even though AI is assisting humans in accelerating software development, developers still lead many aspects of the craft. But it also seems impossible to perform DevOps functions at the required pace without the integration of AI. So, if you wish to release software at a pace that keeps up with modern tech trends, you need to incorporate AI in your DevOps functions.