Prioritizing Workload Automation – Aline Gerew, Broadcom

This is Textron tv. Hey guys, thanks for the throw. We're here with Alene Guru who is head of enterprise automation for Broadcom, and we're talking about the cloud and automation and the lack thereof.

Alene, welcome the show. Thank you. Thanks for having me today.

We have all seen that the pace at which the workloads are being deployed in the cloud continues to exponentially increase, and yet I feel like a lot of this effort is manual. We haven't really sat down and figured out how to automate as much of it as we should have. And are we reaching some sort of tipping point?

Uh, we are, most of our large customers are moving towards the cloud, and as they do that, they are moving their applications to the cloud as well. Right. Which then brings in some complexity, uh, with that, uh, as they move.

Yes. What stops them from automating? Is it just a cultural issue?

Is it we do things the way we've always done them before or is there some other thing at work here? So they continue to automate, but what we're seeing in the cloud is as they move these applications to the cloud, they are looking at, um, various cloud tools to do automation. Um, specifically it could be data orchestration, workload automation.

And um, as they pull in these new cloud tools, they still have applications that are running on-prem or they using disparate tools, um, here and there. So what's happening is there is no central management and that is what is causing some problems. Do you think given the current economic headwinds that there's more people looking into that because there's starting to realize that the total cost of managing all these platforms is significant?

It is, yes. Um, and, and also it's being pushed out to the various organizations. So for example, the application developer may choose a tool in which they want to use and they a cloud tool, for example, it could be Databricks, it could be airflow.

And what's happening is as they're using those tools, those tools are great and they serve the purpose for the application developer, the IT ops person that is responsible for making sure that the workload is being, um, you know, run every day at a certain time. So if the, you know, markets are opening the, um, that they're ready for the, uh, the markets to open, um, they don't have visibility into what those cloud automation tools are doing. So having that manager or manager or a central way in which to manage their workload is what they're looking for.

So in some ways, we're winding up with these islands of automation, but we need some way to kind of create a layer of abstraction above them that makes it easier to invoke the various islands of automation. Is that a fair assessment? That is a fair assessment.

And what's interesting is, if you think back, um, in the history of automation, right? Specifically workload automation. We had this problem 20 years ago when e r P systems, uh, became popular and they were, uh, had their own scheduling and automation within those ERPs.

What was happening is they were using those e r p tools to do their workload. There was no manager of managers, uh, to, to see or have that visibility across all of their workload. Um, they solved those problems.

We have agents for our workload automation tools and now we are facing the si, same exact problem that we faced years ago. It's all happening all over again. Do you think that maybe artificial intelligence will come along and save us from ourselves or what's the state of the art?

I'm not sure it will save us from ourselves, but it certainly, uh, will help. Um, with automating, for instance, um, being able to automatically generate script languaging, uh, that the application developer can use to, um, you know, automate some of the processes, automate some of the data orchestration for example, and that way they, um, can, you know, speed up the, uh, automation as they're developing. It's the democratization of automation basically.

And that might be part of the problem is right now the folks that have the expertise to automate something or too busy holding it together to sit down and write the automation that would solve the problem. So, um, is part of the issue is we don't have the right FO folks focused on the right things. Well, you know, it's the decentralization I think that is causing that problem, right?

Because before IT ops were the central organization that was doing all of the workload automation or, um, along with the application developer. Now we are pushing it out to have people be able to be, to do it themselves. So that is, you know, not helping.

Um, and that's okay, right? That's what we want to happen, but you still need to be able to have that central view, um, unified observability, making sure your SLAs are on, um, running on time or you're not missing SLAs, et cetera. We hear a lot about platform engineering these days.

Is this part of that whole conversation where the automation is kind of the tool that drives the centralization of the management of IT ops, DevOps, and all this other stuff, Right? Exactly. It is the center of all three of those.

What makes it challenging therefore to kinda implement the manager of the managers? How easy is that? I mean, is that getting simpler?

'cause it seems like there would be a lot of APIs involved. So how do I kind of, you know, connect the ankle bone to the knee bone to the hip bone as it were? Yeah, it, it, it's a great question.

So what we have done is provided, uh, integrations to these disparate tools, these, you know, various cloud tools and we've made it easy for our customers to download those, um, integrations so they can from, you know, atomic automation or AutoSys into integrate, uh, a Databricks or an airflow as I've said earlier. And, um, I think we have probably over 75 integrations at this point to various cloud tools. They can manage that workload from our workload automation products.

Who's driving this conversation these days? 'cause to your earlier point, a lot of it is decentralized and you have a lot of small units that, you know, they're trying to hold their own things together. They're not thinking about the larger picture, but who's sitting at the top of the food chain that figures out we need, you know, a, a better approach to automation?

So It, it, it depends, it depends on the organization, but over the last few years what we've seen is the role of a cloud architect. So that person is not necessarily making the decisions on which workload automation tool or um, data orchestration tool that they are using. What this person is doing is helping to organize their move to cloud and then working with a group of people.

And it could be an infrastructure architect, it could be a data scientist, it could be, um, an an application architect and they're, uh, working together to make those decisions. And then what happens is it ops does get involved and sometimes they're getting involved too late, right? Some of these decisions are being made.

And then, uh, again, I go back to the point that I made earlier where they're missing their s l a on their workload. So the, uh, again, the market's open in the morning, their batch jobs have not completed, the data is not available and that's where, um, the rubber meets the road, right? You need to make sure that make you are ready and your processing is complete and it's being taken by surprise in some cases, not all, but in some cases.

So that's where the groups come together and, and decide what are the best tool set for the job. Do you think this effort ultimately will change many of the roles as they exist in IT organizations today? And that's part of this conversation we're gonna have because we have some duplicate efforts here and there that maybe could be centralized and in other places we're not doing other things 'cause we don't have enough skills or resources available.

So, um, we'll one of the consequences all of this be we will rethink the way the IT team is structured. I, I'm not sure if it will change the way that the IT ops team is structured, but it will change the way in which individuals work in the, um, the tool set that they're, you know, implementing or they're integrating to in how they work today. So it will, I'm not quite sure it'll change the, the, uh, persona per se in, in their work.

So what's your best advice to folks? I know you've seen some organizations go down this path before and probably seen a few things that make you shake your head, but, uh, how do I reduce what some of us kindly refer to as the idiot tax when I'm trying to move to automation? Yeah, it, it, we've been talking to many customers and, um, some have gone down a path where they are pushing out those decisions outside of IT ops and, you know, to the application developer for example, and then they're running into problems later on.

So what we've asked them is, you know, take a look at the tool set that you've had for many, many years that you, you know, has done the job for you. Um, look at the integrations that we have and consider having that manager of managers to have that centralized view. Um, you know, that unified observability, the s l a management that goes along with it and look to bring that all together, um, and make those decisions early on before you run into problems.

All right, folks, you heard it here. That ounce of prevention is worth a few pounds of cure and it's always true in the IT space as well. Alene, thank you for being on the show.

Thank you. Thanks for having me. All right.

And back to you guys in the studio.