 Everyone, welcome to theCUBE's coverage of AnsibleFest 2021 with Red Hat. Topic of this power panel is the future of automation. We've got a great lineup of CUBE alumni. Joe Fitzgerald, vice president general manager of the Red Hat business unit. Thanks for coming on, Tom Anderson, vice president, product management at Red Hat, and Alessandro Parelli, who's senior director of product market at Redhawk with CUBE alumni's distinct power panel. Joe, we'll start out with you. What have you seen in the automation game right now? Does it continues to evolve? I mean, you can't go to an event, a virtual event, or read anything online without hearing. AI, automation, automation, hybrid, automation, hybrid, hybrid, hybrid, hybrid. I mean, automation is the top conversation in almost all verticals. What do you see happening right now? Yeah, it's sort of amazing. Automation is quite fashionable these days, as you pointed out. Automation's always been on the radar of a lot of enterprises, but I think it was always perceived as sort of like an efficiency, a task level thing that people did. Now automation is, if you believe some of the analysts, it's up to a boardroom imperative in some cases. So we are seeing with our customers that the level of complexity they're dealing with, particularly exaggerated by what's gone past year and a half in the world, is putting a tremendous amount of pressure, attention, and importance on automation. So automation is definitely one of the busiest places to be. What's the big change this year though? I mean, we love the automation conversation. We had it last year a lot too as well. What's the change? What's the trend right now that's driving this next level automation conversation with customers? Well, I'll ask my colleagues to comment on it a second, but the challenges here with automation is people are constrained now. They can't access facilities as easy as they used to be able to. They still need to go fast. Some businesses have had to expand dramatically and introduce new services to handle all sorts of new scenarios. So they've had to deploy things faster. Security, not a week goes by, you don't read about something going on regarding security and breaches and hacking and things like that. So they're trying to secure things as fast as possible and deploy into critical fixes and patches and things like that. So there's just a tremendous amount of activity that's really been exaggerated by what's gone on in the past year. And all of this has been compounded with a natural increase in complexity that we're seeing in the architecture, the explosion of microservices, the adoption of muscle containers and the adoption of multiple clouds for most customers around the world. So really the extension of the IT environment these days, especially for a large enterprise is enormous for any team, no matter how big it is or how skill it is to really go after and look for all the systems and then the complexity of the architectures is enormous within that IT environment. It is impossible to scale the applications and to scale the infrastructure and not scale the IT operations. And so automation becomes really a way to scale IT operations rather than just keep repeating same steps over and over in an attempt to simplify or to reduce costs as well beyond that at this point. That's a great point, Tom. That's what's your reaction to this because Alexandria brings up a good point. Developers are going faster than ever before. The changes of speed and complexity have gone up. So the demand for the IT and or security groups for anyone to be faster, not weeks, minutes. I'm talking about a complete time shift here. Yeah, so I talk to a lot of customers and what I keep hearing again and again from them is kind of two things, which is the need for skills and re-skilling existing staff when all of a sudden talks about the complexity and the scale, think about all the different new tools, new environments, new platforms that these employees and these associates are being exposed to and expected to be able to handle. So a real skills, not a skill shortage, but a stress on the skills of the organization. And then secondly, really, our customers are talking to us about the culture in the environment itself, the culture of collaboration, the culture of automation and the kind of impact that has on an organization the way teams are now expected to work together to share information, to share automation, to push, you know, we talk about shifting left in a lot of things now in IT, automation is now shifting left, pushing automation and access to subsystems, IT subsystems and resources into the hands of people who traditionally haven't had direct access to those resources. So really kind of shift in skills and a shift in culture I see. The culture, I want to come back to that culture thing, but I want to ask you specifically on that point, do you think automation users still view automation as just repeating and simplifying processes that they already are doing? You heard the expert, they're three times automated. Is that definition changing and evolving? What's your thoughts? Yeah, I think it's really changing, you know, going from the traditional, you know, I'm a network engineer and I use a command line to update my the devices I'm responsible for the config devices. And then I decide to write a playbook using a really cool product like Ansible to drive automation into my daily tasks. And then it comes up to exposing, again, exposing that subsystem I'm responsible for, whatever it is, storage network compute, whatever it is, exposing that up so other people can consume it without me being involved, right? So that's a real kind of change in a mindset and tooling and approach that I'm going to expose that up to a set of workflows, business workflows that drive automation throughout an organization. So that's a real kind of evolution of automation. First, and that's usually focused mostly on day zero, provisioning of a new service. Now we see a lot more focus or a lot of additional focus on day two operations. How do I automate my day two operations to make them a lot more efficient? As my scale and complexity grows, how do I take the human element out of operating this on a day-to-day basis? So you're saying basically, if I understand you correctly, the system's architecture view or mindset around automation is moves from, hey, I'm going to use an Ansible, by the way, it's great for, hey, I want to automate something that I'm doing a lot. That's cool. But you're looking at it differently. If I understand you correctly, you're saying the automation has to be a system view, meaning you create the rules of the road so that automation can happen at the front lines in the CISD Pipelining. You mentioned shift left. Is that the difference? Is that kind of what's happening here that it's beyond just doing automation because you can automate it? So you've done that. There's like a next level. Is that what you're getting at? It is. And we joke about a little bit crushing silos, right? Breaking down silos and again, I keep talking about culture. It really is important. The tools are important. The technology is important, but the culture is super important. And trying to think of that thing from a system's mindset of sort of workflows and orchestration of a business process that touches IT components and how do I automate that and expose that to that workflow without a human having to touch it, right? Yet still enforce my security protocols, my performance expectations, my compliance stuff. All of that stuff still needs to be enforced and that's where repeatable automation comes in of being able to expose this stuff up into these system level workflows. And then there is another element to this, a storage. I think it's really important to attach to this the element of speed. We talk about complexity. We talk about scale, but then there is this emerging third dimension as I call it that is the speed. And the speed has a number of different articulation. It's the speed when you're thinking about how quickly you need to deliver the application. If you're in a very competitive environment, think about web, web-scale startups, for example, or companies in an emerging market. And then you have the speed in terms of reacting to a cybersecurity attacker, which Tom just mentioned. And then you have the third kind of speed I'm thinking about right now, which is the increasing amount of artificial intelligence. So an algorithmic kind of operation. So this is taking place in the organization. For now, it's very limited, but it's no unthinkable that going forward to operations will be driven or at least assisted by artificial intelligence. This speed, just like the scale of the complexity we mentioned before, are impossible to be addressed by a single team. And so automation becomes indispensable. Yeah, that's a great point. I want to just double click on that. I mean, both Tom and Joe were just talking about system, they use the word system. In a subsystem, if one is going faster than the other to your point, there's a bottleneck there. So if the IT group or security groups are like going to take time to approve things or not put rules to the road together to automate, to help developers be faster. Because look at, it's clear, and we've been reporting on this in theCUBE. Cloud developers are fast. They're moving really fast with code. And so what happens is if they're going to shift left, that means they're going to be at the point of coding to set policies on security. So that's going to put pressure on the other subsystems to go faster. So they have to then expose rules to the road or I'm just making that up, but like policy-based or have some systems thinking. They can't just be the old way of saying, no, slow it down. So this is a cultural thing. I think, Joe, you brought up culture, Alexander, you brought up culture. Is that still there, that fast team here and a slow team here? Is that still around? Are people getting faster on both sides? And I'm kind of talking about IT, generally speaking, that tend to be slower than the developers. Well, there's just a couple of comments. First of all, you know, you heard silos, you heard complexity, you heard speed, right? Talked about shift left. Let me sort of maybe tie those together, right? What's happened to date is every silo had their own set of tooling, right? And so one silo might move very fast with a very private set of tools for network management or security or whatever, right? And if you think about it, one of the number one skills gaps right now is for automation people. But if an automation person has to learn 17 different tools, because I'm running on three public clouds, I have on-premise edge and I'm doing things, you know, to network storage, compute security, you know, all sorts of different systems, the tooling gets so complicated, right? But I ended with a bunch of specialists, right? Which can only do one or two things because they don't know the other domains and they don't know the skills. One of the things we've seen from our customers, I think this is a fundamental shift in automation, right? Is that what we've done with Ansible in particular is we actually adopted Ansible because of its simplicity. It's actually human readable. You don't have to be a, you know, hardcore programmer to write automation. So that allows the emergence of citizen creators of automation. There's not like a group in some ivory tower that now can make automation and they do it for the masses. Individuals can now use Ansible to create automation. Going cross-domain. Ansible automation touches networks, security, storage, compute, cloud, edge, Linux, windows, containers, traditional, ITSM. It touches so many systems that basically what you have is you have a set of power tooling in Ansible that allows you now to share automation across teams because they speak the same language, right? And that's how you go faster. If every silo is fast, but when you have to go into silo, you slow down or have to open a ticket or have some impedance in this match. It causes delays, errors, and exposures. I think that is a very key point. I mean, that delay of opening up tickets, not being responsible. John, you put up machine learning and AI. I mean, if you think about what that could do from an automation standpoint, if you can publish the HIPAA rules of your healthcare, you can just traverse that with a bot, right? I mean, this is like the new, this is save so much time. Now, why even open up a ticket? So if you can shift left and do the security and there's kind of rules there, this is a trend. So how do you make that happen? How do you bust a silo zone? I guess that's the question I'd love to get everyone to react to because that implies some sort of horizontally scalable control plane. How does someone do that in an architectural way that doesn't really kind of maybe break everything or make the anachronization go into a cultural sideways situation? Maybe I can jump in and grab this one and then maybe ask all the sonar to weigh in afterwards. But what we've seen and what you'll see, some of the speakers at Ansible Fessus here talk about from a cultural perspective is bringing teams together across automation guilds, JPMC calls it a community of practice where they're bringing hundreds and thousands of individuals in the organization together virtually into these teams that share best practices and processes and automation that they've created. Secondly, and this is a little bit of a shameless plug for Ansible, which is having a common language, a common automation language across these teams so that sharing becomes obviously a lot easier when you're using the same language. And then thirdly, what we see a lot now is people treating automation as code, right? Storing that in Git, version managing it, version controlling it, checking it in, checking it out, really thinking of automation differently from an individual writing a script to this being infrastructure or whatever my subsystem is managed it and automated it as code and thinking of themselves as people responsible for code. These are all great points. I think that on top of all these things there is an additional element which is change management. You cannot count on technology alone to change something that is purely cultural as we kept saying during this video right now. So I believe that a key element to win, to succeed in an automation project is to couple the technology. Great technology, easy to understand, able to become the common language as Tom just said with an effort in change management that starts from the top. This is something that you don't see very often because a technology vendor rarely works with a more consulting firm but it's definitely an area that I think would be very interesting to explore for our customers. That's a great point on the change management. I may ask you, what do you think it needs to make automation more frictionless for users? What do you see that needs to happen? How's that? I think there are at least a couple of elements that need to change. The first one is that the effort that we're seeing right now in the industry to further democratize the capability to automate has to go one notch further. And by that I mean implementing self-service provisioning portals and ways for automatically execute an automation workflow that already exists. So that an end user, somebody that works in a line of business and doesn't understand necessarily what the automation workflow the script is doing, still able to use it to consume it when she or he needs to use it. This is the first element. And then the second element that is definitely more ambitious is about the language about how do I actually write the automation workflow? This is a key problem. It's true that some automation engines and some workflows have done historically speaking a better job than others in simplifying the way we write automation workflows. And definitely this is much simpler than writing code with a programming language and it's simpler than writing automation compared to a tool that we used 15, 10, 15 years ago. But still there is a certain amount of complexity because you need to understand how to write in a way that the automation framework understands. And you need, even before that, you need to express what you want to achieve in a way that the automation engine understands. So I'm thinking then going forward, we'll start to see artificial intelligence being applied to this problem in a way that very similar to what OpenAI and Microsoft are doing with Codex. The capability that is a model that allows a person to write in plain English through a comment in code to translate that comment into actual code taken from GitHub to the machine learning process that's been done. I'm really thinking and going forward, we'll start to see some effort in the same direction but apply to automation. What if the AI could assist us and replace us in writing the automation workflow so that more people are capable to translate what they want to achieve in a way that is automated. So you're saying the language, making it easy to program or not to program or write or create, being the creator of automation and then having that be available as code with other code. So there's kind of like this new paradigm of automating the automation. In a sense, it's absolutely true, yes. In addition to that, John, I think there's another dimension here which is often overlooked which we've spent a lot of time on. It's one thing to have things like Alessandro mentioned that are front edge in terms of helping you write code. We want to know something in big organizations. A lot of times what we find is someone's already written the code that you need. The other problem is you don't know about it. You can't find it, you can't share it and you can't collaborate on it. So the best code is something that somebody's already invested the time to write, test, burn in, certify. What if they could share it and what if people could find it and reuse it? Everybody's talking about low code, no code. Well, reuse is the best because you've already invested expertise in doing it. So we've spent a lot of time working with other customers based on their feedback on building the tools necessary for them to share automation, to collaborate on it, to certify it and also to create that supply chain from partners who create integrations and interfaces to their systems, right? And to be able to share that content through the supply chain out to our customers and have them be able to share automation across very large globally distributed organizations. Very powerful. That's a powerful point. I mean, reuse, leverage there is phenomenal. Discovery engine's got to be built. You got to know, I mean, someone's got to build like a search engine for the code. Like, hey code, who's written some code? But just a whole nother mindset. So this brings up my next question for you guys. Because this is really, we're teasing out the biggest things coming next in automation. These are all great points. They're all about the future. Where will the puck be? Let's skate to where the puck will be. But it's computer science and automation that's being democratized and opened up more. So it's, what do you guys think is the biggest thing coming next for automation? Joe, you want to go next? Sure, sure. Yeah, I'll take it. So we're getting a glimpse of that with a number of customers right now that we're working with that are doing things around concepts like self-healing infrastructures. Well, what the heck is that? Basically, it's tying event systems, right? And AI, right? Which is looking at what's going on in an environment and deciding that something is broken, suboptimal, spending too much. There's some issue that needs to be dealt with. In the old days, it was, that system would stop with opening a ticket to dispatch some people who would either manually or semi-automated, go fix, repair, whatever. Now people are connecting these systems and saying, wait a minute, I've got all this rich data coming through my eventing systems. I can make some sense out of it with AI or machine learning, right? Then I can drive automation. I just eliminated a whole bunch of people, time, exposure, cost, everything else. So I think that sort of venture automation is going to be huge. I'm going to argue that every single system in the world that uses AI, the result of that's going to be, I want to go do something. I want to change, I want to optimize, I want to move, secure, stop, start, relocate. How's that going to get done? It's going to get done with automation. And what Joe just said is already highly successful in the consumer space. If you think about solutions like if this, then that or Zapier, for example, those are examples of even driven automation that have been in the consumer space for a long time and they are wildly popular to the point that there are dozens of clones and competitors. The enterprise space didn't adopt the same approach so far but we start to see even bridges and even hubs that can really outdo with this. And this really connects to the previous point at this point on a broken record which is about the speed of the complexity. If the environment is so spread out and so complex and it goes all the way to the edge and all these events take place at a neck breaking pace, the only way for you is to tie the automation workflows that you are written to trigger an event that takes place at some point according to your logic. Tom, what's that? Yeah, last but not least on that kind of thread which is sort of the architectures as we get out to the edge. What does it take to automate things at the edge? We thought there was a big jump from data center to cloud and now when you start extending that out to the edge am I going to need a new automation platform to handle those edge devices? Well, I need a new language, well, I need a new team or can I connect these things together using a common platform to be available to automate at the edge? And I think that's where we see some of our customers moving now which is automating those edge environments which have become critical to their business. Awesome. I want to ask one final question while I got you guys here in this power panel. Great insights here. Operational complexity was mentioned, skills gaps was mentioned earlier. I want to ask you guys about the organizational behavior and dynamics going on with this change. Automation, hybrid, multi-cloud, all happening. When you start getting into speed, speed of application development for the modern apps, open source where things are opening up and things are going to be democratized with automation and code and writing automation and scaling that. You're going to have a cultural battle that's happening and we're kind of seeing it play out in real time. DevOps has kind of gone and been successful and we're seeing cloud native bring new innovations. People are refactoring their business models with cloud technologies. Now the edge is here. So this idea of speed shifting left from the developer standpoint is putting pressure on the old incumbent systems like the security group or the IT group that's still holding on to their ticketing system or, and they're slower. They're getting requests and the developer's like, okay, go faster. I want this done faster. So we're seeing departments reorganizing. What do you guys see? Because Red Hat, you guys have been there all these big accounts for the generation of this modern era. What's the cultural dynamics happening and what can companies do to be successful to get to the next level? So I think for us, John, so we certainly see it and we experience it across thousands of customers and what we've done as an organization is put together adoption journeys, consulting engagement for our customers around an automation adoption journey. And that isn't just about the technology itself for Red Hat technology. It's about those cultural things thinking differently about the way I automate and the way I share and the way I do these tasks. So it's as much about cultural and process as it is about technology. And our customers are asking us for that help. You know, Red Hat, you have thousands of customers that are using this product. Surely you can come and tell us how we can achieve more with automation. How can we break down these silos? How can we move faster? And so we've put together these offerings both directly as well as with our partners to try and help these customers kind of get over that cultural home. Awesome. Anyone else want to react to the cultural shift and dynamics and how it can play out in a positive way? Yeah, I think that it's a huge issue. You know, we always talk about people, processes and technology. Well, the people issues are really a big deal here. You know, we're seeing customers, huge organizations with really capable teams building apps and services and infrastructures saying, help me think about automation in a new way. The old days, it was, hey, I'm thinking about it as a cost savings thing. Yeah, there's still cost savings in there. To your point, John, now they're talking about speed and security and things like that. How fast, you know, zero day exploits. Now it's like zero hour exploits. How fast can I think about securing something? You know, you know, time to, you know, heal, time to secure, time to optimize. So people are asking us, what are the best practices? What is the best way to look at what I've got? My automation deficits, right? You used to have tech deficits. Now you got automation deficits, right? What do I need to do culturally? It's very similar to what happened with DevOps, right? Getting, you know, teams to get together and think about it differently and holistically. That same sort of, you know, transition is happening and we're helping customers do that because we're talking to a lot of them where we've got the scars and then through it. Awesome, Alexandra, your thoughts on this issue? I think that what Tom and Joe just said is going to further aggravate, is going to happen more and more going forward. And there is a reason for that. And this connects back with the skill problem that we discussed before. In the last 10 years, I've seen growing demand for developers to become experts in a lot of areas that have nothing to do with development, code development. They had to become experts in cloud infrastructures. To become experts in security because you probably heard this many times, security is everybody's responsibility. Now they've been asked to become experts in artificial intelligence, transforming the title in something like ML engineer, the amount of skills and disciplines that they need to master alone by themselves will require a lifetime of work. We're asking human beings to get better and better all the space and all the best practice. It's absolutely impossible. And so the only way for them, yeah, five jobs in one, six jobs in one, right, probably for the same salary. And the only way that these people can execute the best practice, enforce the best practice, if the best practices are encoded in automation workflow, not necessarily written by them, but by somebody else and execute them at the right time, right context for the right reason. It's like the five tool player in baseball. You got to do five different things. I mean, this is, you got to do AI, you got to do machine learning, you got to have access to all the data. You got to do all these different things. This is the future of automation and automation is critical. I mean, I've never heard that term, automation deficit or automation debt. We used to have a tech debt but I think automation is so important because the only way to go fast is to have automation kind of at the center of it. I mean, this is a huge, huge topic. Thank you very much for coming on. It's a power panel on the future of automation. Joe Tom and Alcindor from Red Hat. Thanks for coming on everyone. I really appreciate the insight, great conversation. Next time. Okay, this is theCUBE coverage of AnsibleFest 2021 virtual. This is theCUBE. I'm John Furrier, your host. Thanks for watching.