Brad Maltz, Dell Technologies | DevOps Experience 2022

Hi everybody Brad malts here. I'm a senior director of the devops portfolio and the devrel organization at Dell Technologies. And today what I'd like to talk to you about is how devops is not your final destination.

I believe there's more beyond devops that you are going to have to drive towards. Now before I get into the slide deck, I want to make sure that you understand kind of at least a high level view from two seconds of what I mean by devops when I talk about devops I'm talking about how devops is the operating model to cultural shift that the business is trying to go through to allow operations to align closer to the application developers in the business. and with that being said what's Happening Here is in a devops model.

There's a notion that application developers start doing more operations. Well, that's just not the case. Where the application developers are really trying to do is their job is to deliver application features and application code to the end users the customer base of the business.

That means that they don't want to go and work on operational automation work on support of the applications from a infrastructure up perspective. So in this world when we talk about application developers not wanting to do operations. That means the operations falls back onto the actual it Ops people.

When we talk about the it Ops person, of course, they've been working in this world for a very long time. They've been doing storage operations server operations Network virtualization. You can go up and down the stack and it Ops is always worked at the command line.

They've always had to do things like bash scripting Powershell as well as working within the element managers. But what devops is introducing and the notion of cloud native Technologies? Is that finally they have to figure out how to actually go beyond our shell and Beyond standard scripting practices.

They have to learn to get closer to a software developer. They have to learn languages and and a Concepts that are pushing the boundaries of what their existing knowledge base is and when you talk about what they're really forced to think about in this world a developer from an infrastructure developer standpoint. That is the devops person type of role.

Now. We're talking about automation Technologies, right pipeline management the developer tools for their end user who is the application developer. There's a lot of these Concepts that are being thrown at these devops people.

Well part of the problem they're running into is they have all this stuff being thrown at them? They still have to figure out how to manage more of the traditional Legacy stuff. Unless you're totally born in the digital age and you don't have to deal with Legacy applications.

And the reality is as they're going through this there's other pieces of the business that have to get pulled in and this is where I believe devops is not the end state. Now just to kind of continue down the devops discussion that we're having for a minute. One of the enablers in the bigger context of devops in the industry right now is the abstraction right?

And this is where things like virtualization for the past 20 years or so is really taken off and become the de facto standard abstraction and more recently probably over the past five or six years kubernetes has now kind of superseded that as the next level abstraction. And as we talk about that the abstractions are key whether you're talking about abstractions up in the devops level at the data level across clouds. This is really where the notion of moving beyond devops starts to get interesting because the reason kubernetes and the abstraction has one here.

Is it gave folks the ability to encapsulate the application which prior to kubernetes it was kind of like the Wild Wild West and how you dealt with applications when an application developer delivered an application. It could be packaged a million different ways. It has specific requirements that were very unique to the application without any standardization under the covers.

Kubernetes is kind of trying to constrain that into a world where the abstraction of kubernetes actually is helping devops become more proficient and efficient and what they're actually going to do. Now taking that one step further is where automation comes in and again hitting on the Ops side of devops. Your job as the it Ops person that's transitioning into a devops operating model is to automate your own job.

The things you would have done manually before. When you start thinking about how you want to go down the road and automate your OS deployments. Or if you want to automate your server and storage pieces of the landscape.

The goal there is you would have been doing these manually before. Or you would have had some processes within the organization. Where it made sense for how you ran the process but they were still manual processes even though you document.

When you get into an automation conversation, the goal here is to understand how you were doing those in a manual world. Understand if the manual way is still the right way going into the new world and sometimes just got to mimic that manual way within code using tooling like ansible and terraform. And when you go down that road, then what you're really looking at at that point is how do I keep building my portfolio of automation to stop having to run those manual processes?

And this entire Continuum is more of an Ops conversation than is a full Dev conversation. You need to use Dev skills in this world, but you're doing it from an IT operations infrastructure developer perspective. now the issues that I'm seeing happening in the industry are this is this is age-old these are not new right one of the biggest ones that's out.

There is the notion of boundaries sometimes people are asked to kind of not do something because it's not part of their team. There's a political boundary an organizational boundary. And when you're dealing with the boundaries in this case, that's what you need to start to break down when you're trying to solve operational efficiency conversations, whether it's devops or any other operational types of conversations.

You also have people that love to drive process and one of the other pieces of this operational transformation that people have to go under. Is to actually become more agile. And in agile World sometimes heavy process or actually most times.

I'll say heavy process is actually the enemy. What we're actually looking to do is as you try to figure out to break down the boundaries. You also have to understand how to optimize the processes.

And the key there is to have everybody targeting the same outcome. We as a business want to go fix this problem. We as a business want to become more agile from an operational perspective.

The last part is what we call and you've heard this before. It's not new the golden path of the paved Road, right? It's a concept that's been in devops for for many many years.

And when a business is first trying to make that pivot into a devops mindset or devops culture. One of the first things they're dealing with is my developers have been using like a hundred different tools and a hundred different platforms. And how do I Wrangle that down?

And sometimes you have to start with a ton of constraints and that's where the golden path kind of comes in. It's the ability to give your end users your consumers a structured constraint set of tooling and platforms that you have the ability to operationalize as simply as possible and they have the ability to deliver against their jobs also as efficiently as possible. So these are three issues that I see popping up across the board when we deal with any type of an operational transformation.

Now what we're going to spend the rest of the session on is actually this slide. I have no more slides which should help a lot and we're what I believe is devops is as you can see here. It's the tip of the sphere.

It's the first leg of the trifecta as we sometimes talk about it. Because as we just described in a devops world devops is going after infrastructure and application Level automation lifecycle management types of things that includes everything from platform tooling for developer, tools pipelines all the way down through the infrastructure as a service platform as a service type of stuff including how you package and deliver the applications on top of a containerized kubernetes style world or even it may be in a legacy-ish oriented virtualized world. Well, if a business achieves some level of maturity in devops, they're still missing the two other pieces.

The first piece is data Ops. As you've solved the infrastructure and application side of the house. The business still needs to understand how their data is being operationalized how it's being utilized how it's being governed.

Anytime that you build an application. There's some level of data. It could be a fairly stainless application.

That's ephemeral that is maybe creating a little bit of very lightweight Telemetry on the back end or logging or some other stuff all the way down through your super heavy data oriented applications like AIML applications or databases or other types of apps like that in that case the business starts to understand. How do we make sure that the data sets not Storage storage is encompassed under the devops side of the world. From a data Ops perspective you're thinking data set buckets file systems, right that's said that level of data and you want to make sure that you're controlling access to the data.

You want to make sure that you understand the location of the data such that when the application is put into a certain location whether it's in the public cloud or on premises or at the edge. Then the data is in the right spot wherever it needs to be whether it's on the receiving end somewhere else at the application can reach it or is localize and the same locality as the application. So data Ops another part of the business that you as a end user have to start contextualizing to really move into a much more efficient and operationalized world.

Now these two pieces together are very interesting. But one thing that's missing is the business level controls. You have some of those with governance and compliance in the data Ops game.

You're missing the financial side. This is where finox comes in. What happens here is if devops is going after infrastructure and application workload placement and kind of life cycle management.

Then it has the ability to automate deployment of all those things and usage of all those resources across a multi-cloud world and on-prem world or even at the edge. and you can do that through a lot of the tools that we've already been talking about on the backend. And the data Ops does the parallel effort from a data set perspective?

what we haven't talked about is Is it the right location based on the cost based on the procurement side of the business from a financial perspective, what you need to do is you need to start applying some of those cost Dynamics to make a decision that says in a devops world. I should be using this Computing storage resource in this location tied to this application because maybe for the next six months. It is more cost effective based on the resource needs.

And the other part of the trifecta is from a data Ops perspective. The data also is living there and all of a sudden you can start building an algorithm. That takes into account the cost metrics with the data governance and data life cycle mixed with the infrastructure and application resource needs.

That's when you start to really get to this point where you as a business have gotten fully operationalized. Now, of course when you look at this world a lot of the industry myself, we actually use the term exops. Which is when I believe you're traversing Beyond devops, which is one corner of the universe and you're moving into trying to get to a much broader operational landscape.

There's a lot of other Ops terms that are out there and I think this is what I want to connect some dots for you as well. Get off right? This is one that's much more of a Technology based conversation, especially in the devops and data Office Space.

The notion with Git Ops and and companies that are able to really become mature in the GitHub space. They're kind of some of the stronger way way more mature of the devops customers I've seen right now. The notion is you are handling Version Control from a git repository with A continuous deployment mechanism tied to the front end of it.

So as I just walked you through it's a very technical side of this which is all about continuous deployment and delivery. Mixed with the notion of using code in more of a declarative way to manage State and Version Control in the deployment scenario a getups conversation is still important with the trifecta because as I said, you do it today in the devops space, but guess what data Ops all so over time will actually have implications here. Because we should be able to version out data in the same way that we actually control versioning of infrastructure and applications which means the git Ops principles over time should be able to be applied to data set management.

And then when you apply financials in the decision tree of how get UPS actually works now you start to become more interesting and actually automating the full life cycle of that. another part of this another term is ml Ops machine learning Ops In the data Science World, right the AIML space. This is another term that's very popular and I actually like to embed.

Ml Ops across the devops and datops just like getups. For me the definition of ml Ops here is really the notion of we are building machine learning models and we have to manage the life cycle from training all the way up front creation. All the way through in deployments and inference all the way out through the edge and that means you got to deal with the life cycle of the data from training through inference.

You have to deal with the Model Management under the covers which by the way is where githubs actually gets really interesting to tie them together. And when I look at ml Ops, it's really a subset of devops and data Ops because the machine learning models are really an application Level deployment scheme that you deal with in devops. They're just very well defined and specific from a requirements what I mean by well defined is they tend to need gpus or CPUs from a resource perspective.

They tend to need certain types of data depending on the model you need but you can understand the resources really nicely depending on how the model is being built. So very well defined the real-time defined applications or what lives in the ml Office Space. The last option I'm going to kind of cover today is what we'll call AI Ops and this one is I would say a little bit more of a marketing term in the industry in my opinion from an AI Ops perspective depending on your definition.

It could be how you use artificial intelligence to kind of do a lot of what we're talking about here. And I'm going to take that same angle, which is it with AI Ops if I have all the criteria and the processes and the policies from devops. Same thing from data Ops same thing from finops.

Now across all three of those I should be able to build a fairly robust set of machine learning models and artificial intelligence models that allows me to turn those potentially originally automated processes into continuously automated processes in the AI Office Space. What I mean by that is when you are building Automation in a devops space, you're still managing the automation scripts. You still need to life cycle manage how that workflow is going to be used as everything else gets a version under the covers.

Get off starts to help there. But what you really want is you want a intelligent enough model under the cover is that's watching that workflow with a defined set of criteria that it's actually able to perform the automation for you without having you needing to give any inputs into it. And this is why I believe until you get to a devops data Ops finops type of Trifecta.

You're never going to get to a true maturity level with AI apps which at this point you're talking many many years down the road because we still have the other pieces of it that we're still working on at this point. So from a Dell Technologies perspective, we do play across all these we're always looking at how these are coming together because our customer base especially since they're heavily on-prem mixed with a multi-cloud deployment today and growing into the edge. We're trying to understand how you can become a much more mature xop shop going forward and I hope today maybe I've framed it up in a different way that helps you understand my point of view and kind of what we've been talking to customers about out in the industry.

So with that being said, thank you very much. I hope you had enjoyed listening to this and have a good rest of conference.