Breaking Silos and Managing Data Across On-Premises and Cloud with Pure Storage

Thank you so much, David. Hi everyone. My name is Ben Li.

I am a technical director here at Pure with a focus on pure fusion. So some of you may have heard of, uh, fusion. We actually did a session on Fusion at Top Fuel Day, uh, several years ago, but that was on Fusion version one.

Today we're here to talk about fusion version two, which has been redesigned to be fully integrated with purity and to be a core enabler of the enterprise data cloud architecture that David was talking about. So, while Fusion V two shares many of the goals of Fusion V one, the how the means by which we achieve this goals have changed, and also we have become more precise on the main goal that we're going after. And that is users now should be thinking about how they should be managing that data could be anywhere across the data estates, OnPrem or in the cloud, and they should not have to be thinking about how to manage their storage infrastructure.

So let's dig in before that, the obligatory legal disclaimer. So we will be making forward looking statement in this presentation. Yeah, go Ahead Kimberly Bates.

Um, so I was familiar with Purity one I confusion, I'm sorry, confus one. Can you go back and state again why, what did you revisit when you went to two? 0?

So there were a number of things that we wanted to, um, to fix or to solve with, uh, fusion V one. So the first one was on backward compatibility. So Fusion V one introduced its own object model, introduced its own paradigm of managing storage.

It had like a, a very prescriptive way of enforcing provider consumer separation. There's like an object model for the provider. There's an object model for the consumer.

And so what we realized was a lot of our existing customers who are very used to the purity way of doing things, they have automation, they have scripts, there's workflows built. Using the existing paradigm in order to adopt the Fusion V one object model requires a complete lift and shift migration. So they have to rewrite their scripts, they have to retrain themselves on what the new object model means, and many of them are on the journey towards, uh, self-service provisioning.

They're not completely at the end yet. So you see many of our customers, they're still, uh, the storage team is still doing most of the provisioning. They're not really handing off the keys to the kingdom, so to speak, uh, for the lines of business to be doing self-service profit.

So they don't really need a strict enforcement of provider consumer separation. And so the, what they are gaining the ROI for doing the lift and shift migration is not really paying off. So that's like the first big consideration is on how do we, uh, have backward compatibility so that the existing customer base can benefit from pure fusion.

The next uh, big consideration was, uh, for duck site customers. So Fusion V one was a cloud control plane. So in order to benefit from Fusion V one, you had to connect to the cloud.

And um, it's not just connecting to the cloud, it's almost remote management from the cloud. So you could just log into the cloud portal, set up your policies and start managing your infrastructure from the cloud. And not just duck set customers, but we have like big enterprise customers that were nervous about it, understandably so.

And they said, yes, we can do this, but the security clearance itself is gonna take years to get through. And so there's like friction here and there just to be able to adopt a platform where you could do remote management from the cloud. That said, there are some customers that are more than happy to do remote management from the cloud.

It's just that we wanna be able to target as many customers as we can. And so an architecture where the control pin itself is built into purity where you can just, uh, upgrade to the latest version of purity and you just get it turned on with just a few simple clicks, it's gonna allow us to get adoption so much more easier. We move friction rather than just going after customers that are comfortable with a cloud control plane.

So like these were the main considerations to switch over to, uh, the new architecture. So, um, coming back here, um, we will be making forward looking statements. Um, but to be clear, fusion is generally available today.

So a lot of what I'm gonna be talking about is available to you today just with a simple upgrade of purity. It's just that you'll be going to be seeing some things in the demo, which we are still currently working on. So those might change.

And so throughout the presentation I'll try to make it clear what's already available, uh, and what we are still currently working on. Great. I get to just a little louder towards Jason.

Yeah, no problem. This is this good. So here at Pure, we are obsessed over simplicity.

We would go to very, very large extents to try to make things as simple as possible. And the reason is simple. When you make things simple, you reduce the opportunities, you reduce the challenges of somebody making an error.

And so the operational costs of running pure arrays, the operational costs of using our products goes down. And so the simpler you can make things, the more likely people are not gonna make, make mistakes. And so the labor costs and the cost, the TCO of operating the arrays goes down.

And again, to be clear, it is still very simple to manage a handful of arrays or a handful of workloads. The problem is, as your environment grows, as you manage more and more arrays, as you manage more and more workloads, then all the minor differences between the workloads between arrays start stacking up. And so what was once manageable quickly becomes unwieldy and could simply, as David alluded to, the traditional storage architecture, which is vertical and silo is unscalable from a manageability standpoint.

So you have your database stack, you have your virtualization stack, you have your dev test stack, and for each one of these stack you find yourself having to provision and configure workloads over and over again. It might be very similar workloads, but the fact that you have to do this over and over again means that you are inevitably creating a lot of resources. And by resources I mean like your export policies, your quota policies, your protection groups, things that are used to configure your workload, and just having to configure each and every one of them all the time and having to get them right leaves you open to make mistakes.

And it's a risk. So sometimes what you really want is for you to be able to define like a protection policy once and use it everywhere in your data estate. But because your architecture is siloed, you have to duplicate the protection policy.

You have to create the same protection policy in your database stack, in your virtualization stack, in your desk stack, and so on and so forth. And god forbid, requirements change. Now you have to go update every one of the policies and you're not even sure if you have got got them or, and so management at scale is challenging.

And if I were to think back, back in the days, the instructions to be able to manage a pure array fits in a business card. And then over time it grew into like a double-sided business card. And eventually it grew into something that looked like this.

So a 10 cut still fits very nicely. It's very easy to operate a pure array. But as you start managing at scale, the instructions just keep growing and growing.

You, you find yourself looking at round books, you find yourself looking at spreadsheets. And so where we really wanna go is to go back to where we can just have instructions that fit in the business cut, but at the same time be able to manage at scale. And so here's where Fusion comes in.

So to reintroduce Fusion, fusion is now just another purity feature. So if you are on the right version of purity, that's six nine oh and above for flash array and 4, 5, 6 and above for Flash Blade Fusion is in that purity version. It's ready for you to use, it's ready for you to turn on and consume with just a few simple clicks, just like any other purity feature.

So you don't have to deploy like a separate virtual machine. It's not on an external control pin somewhere else over there. You don't have to connect the arrays to the cloud.

If you do, you will get an enhancement in the form of a recommendation for where to replace your workloads. We use the P one for that. Uh, but that's just using the phone home connection to, to make work.

So the idea for how we get that simplicity for management is we want the storage admin, we want the consumers to be able to define their outcome. So just what they want the outcome declaratively in this thing we call a preset and then hand the preset over to Fusion. They would automate towards the outcome, they would provision the workload, they would configure it, and they would monitor it.

So that what you get at the other end is consistent configuration that meets all of your standards and policies in your environment. Fusion also introduced, introduces this thing called a fleet. So a fleet is where multiple arrays can talk to each other and can coordinate among each other.

So as you can see in the diagram over here, you can have flash array, you can have flash blade, you can have pure storage cloud all in the same fleet. And you can create a preset, you can define it once and you can use it anywhere in your fleet. So now you just have to create a single storage policy that says how a database workload should be provisioned, for example, and use it consistently on your flash arrays, on your flash plates, and on your pure storage clouds all in the same fleet.

Now this gets storage admin thinking about managing their assets as the fleet instead of having to manage individual arrays. This is what we want. We don't want them to have to access and configure each array.

We want the fleet to be the unit of management. So the ideal case is a admin should be able to go to any, arrange the fleet and just say, okay, here's a preset for maybe provisioning database workload. I wanna provision say Oracle Database Fusion.

Please go ahead and do your magic. So based on the, uh, requirements in the preset, based on um, the different load and capacity, uh, characteristics of the different array of fleet Q1 will now make a recommendation. Oh, okay, based on, uh, what we think you want, this array will be a good fit.

And so fusion would go ahead and provision the workload there. Now, on the same array, the admin can say, okay, now I wanna provision a vm maybe like, it's like a VDI desktop vm. So they use like the VDI preset, same thing, get a recommendation this time maybe we want to provision the, um, the VM on this array fusion.

We just take the preset and provision the VM on that array. All of that done from a single array, any array in the free without having to go into each array individually to configure them. Right.

A couple questions. So on the, on that last point, um, in the past, obviously Pure has had block devices and file devices, are you saying that one array is doing everything? Um, not quite.

So flash array still only does block and file flashlight still only does file an object. Uh, we are going to introduce object to flash array, uh, soon. This is a forward looking statement.

Mm-hmm. Um, but what we are saying with Fusion is that we introduced this thing called a preset. You can use preset to deploy block workflows.

You can use preset to deploy. I Get, I get that. So, so you're talking about compliance and stuff.

Are you, so, but it sounds like, you know, you, you wanna manage at the fleet level. Great. I get it.

Um, but what is being managed at the fleet level automatically by purity? Sounds like our workloads not the data. Like are, are, are you, are you looking at the data itself for compliance?

'cause you, you put the word compliance up there, um, and compliance, you know, from what I'm sitting at around and talking to customers about compliance, talking about, you know, what's in the data, where it can be, where it can't be, how it has to be deleted, that kind of compliance, you're talking about compliance to policies of snapshots and replication, that's conformance more than compliance, wouldn't you agree? That's exactly right. So right now the focus for pure fusion is on manageability.

So it's really about like config drift or config conformance. Okay. Making sure that like the workloads are configured correctly.

Uh, and your fleet would still be heterogeneous. You'll still have flash air if you need block workloads, it'll still be flash blade if you need object. And if you need both, you'll likely have a mix of both.

But what we want to avoid is training users to, okay, if you need block workload, here's slash array way of doing things. If you need object workload, here's slash way of doing things. We want a consistent management paradigm where like, if you need any workload, you define a preset and just have fusion, figure out which platform to provision the workload on.

But the underlying capability is still dictated by which, like, uh, hardware you're using for your, for your data. I, I have a question. Yeah.

Nathan Nielsen with, uh, WWT, um, so from your, the predictive, um, recommendations, is that, is that based on like that single environment, based on what it thinks you're probably looking for, it will make those predictive recommendations? Or is it other environments as well that it's taking like data points from and saying, based on what we're seeing in the entire industry, you're, you're kind of probably looking for this. So here's the recommendation.

So it's looking at both. So the arrays in your organization is constantly phoning home. So we get telemetry data, we know that the load and capacity characteristics, and we can have enough data to make prediction like 30, 60, 90 days from now.

Like how, um, much capacity or how much load is gonna perform. When you're provisioning a workload, you also get to specify a workload type in your preset. So we know that you are provisioning like an Oracle database or like A-V-D-I-V-M or like ASAP HANA database and that workload type, uh, we have all of our customer base data to know how this kind of workload would perform in 30, 60, 90 days.

And based on other information, the preset, like how many volumes like the q os you apply to it, like the snapshot retention, we have a rough understanding of is this like a small, medium or large Oracle database deployment. And so based on all of our customer base data, we know roughly how this is gonna perform. And we now overlay that on top of the, your existing array projection.

And we can tell that if you were to provision your Oracle database on this array, this is how the array is gonna perform in like 60, 90 days. Okay, Good. And yeah, using that information, the P one gives a score on the placement, and if it exceeds a certain score, then it's called a recommended array.

If it's below a certain score, then it's, but it meets all the other basic requirements. It's called an acceptable placement. So are, are those KPIs scores, or I mean, or is it, it's it's predictive, right?

It's predictive. It's thinking that this, it's not necessarily on based on how, what it's already seen and experienced. Correct.

But it's predicting based on what it's already seen, but it's predictive financial. Yes. And coming back to Fusion to help with the, uh, vision that you want to be able to go to any array to manage every other array.

We've also introduced FleetView that's now built into purity on every array. What FleetView allows you to do is to monitor and manage resources on every array. So this is built into your gui, this is built into CRI.

This is built into all of the existing APIs. So for example, previously you would run the pure Vault list command on an array to be able to list the volumes on an array. But now we have added a new flag dash dash context, and you can enter the name for remote array to list the volume on.

So now you can log onto array one and do pure vault list dash dash context array two, and you can list the volumes on array two. You can also specify multiple arrays in dash dash context. So you can do pure list dash dash context array one comma array two comma array three.

And you'll allow you to list volumes on array one, array two, and array array three. So in the gui, you can now use this as a single pane of glass to monitor and manage your entire fleet. Are these all feature complete with each other?

Meaning anything I could do in the gui, I could do in the CLI or the API, are there certain capabilities or features that I can only use through one interface or the other? So right now that is true. Uh, but traditionally we are an API first company.

So if there's like bleeding edge feature, sometimes we have API that has the feature first. Yeah. Okay.

And then GUI will catch up later, but as of right now, fleet View is available on A PIC and gui. Okay. Okay.

So let's just walk through an example of a workload provisioning. So the scenario I want you to imagine is, uh, say you're a storage architect and a storage team with a few junior admins. And one day somebody just decides they want to set up a new database and they are calling the storage team to provision, uh, storage for the database.

And that's like a jaded storage architect. You know, it's never quite that simple. You know, you have to go figure out what the data protection requirements are, what the performance requirements are, what the disaster recovery plan is, which area to deploy, and so on, so forth.

There's like so many questions and you usually are the ones that's doing the job, but right now you are tied up with something and you are thinking maybe this is the right time for the junior admins to gain some exposure. So they should like try, try this out. But at the same time, you wanna be able to set up some guardrails so that the admins are guided to do the right thing thing.

So without fusion, how would such a customer set up the guard rails? Invariably, they would come up with a checklist, like, we have checklist for doing this. We have a checklist for doing that.

So here's, uh, example checklist for how would you provision a database workload. So you have a lot of questions like, okay, how many volumes do you want? What kind of volumes do you want?

Do you need volumes for your data volumes? Do you need volumes for your lock volumes, your archive volumes, and so on and so forth. What snapshots of policies do you want?

Like what's the frequency? What's the retention, uh, and what's the secondary retention? What TOS do you need?

What application do you need? And then there's gonna be a lot of additional questions like, did you remember to check the P group? They didn't remember to check that the volumes are placed in the P group.

You didn't remember to check the V group. So there's all these questions along the way in your checklist that a junior admin would just go bang, bang, bang and uh, hit this true. Now the problem is, okay, imagine the storage is provisioned successfully.

How do you know that the admin, the junior admin did follow the instructions carefully? All you can do is trust, or you can do the check on behalf of the user, and god forbid the requirements change. Imagine the lines of business say, oh, I actually meant to take snapshot at this frequency.

Instead of that frequency, now you have to go change the checklist. You have to go change all the workloads already provisioned, and this is where things start getting risky. And you might start seeing things are misconfigured, if only there was a way to be able to cod this checklist and automate the enforcement of all of this, uh, configuration.

So the demo that I'm gonna show Brent. Yeah, just one second. So, so fusion runs on all pure, right?

There's not, there's not a mix of or compatibility for other devices, right? So it's it's managing pure, it's Managing pure. That's correct, yes.

Um, but within that, there's a wide variety of potential resources, potential devices, you know, um, poten, a mix of block file and object and so forth. Mm-hmm. But Fusion is unifying all of those.

That's right. So that's the, And I have a follow up question, but go ahead. Yeah.

That's the unified data plan that David was talking about with enterprise data, cloud architecture. So the thing that Fusion has going for it is because both flash array and flash are both running the purity operating system already. Yeah.

So a lot of things have been unified already. So, And I think you said backwards compatible as well. Yeah.

Or is that, uh, it Is backwards compatible? Yes. So the existing APIs that, um, customers are using today to provision like their block file object workload, we're just adding a little bit more flex like, uh, context flag so that they can now target other arrays.

But other than that, it still works. When you are provisioning a workload from a preset, you're still provisioning the same underlying resources. So you're still provisioning volumes or file systems or managed directories resources that, uh, the users appear to date already understands and are currently using.

So I think one of the biggest headaches involved in, um, uh, setting up, uh, a service, a storage or data service for a workload has to do with the huge variability in, in, in, in infrastructure. Um, I think that's a lot of what drives us towards silos is 'cause it can be easier just to set it up fresh, so to speak, manage it fresh. And we're not just talking about, you know, file structure, storage size, or any of those sorts of things.

It can have to do with, uh, connectivity, networking, lo locality, like lots of stuff. And I'm just wondering to what degree fusion can, you know, pick the array or pick the, the device, um, or mix and match in order to meet the requirements or if it's more of a, you know, software based configuration of each of each device. So we completely understand like the variability of infrastructure, but like, because of that And your bandwidth can cause a choice to be made, a trade off to be made.

So Yeah. But to us, that's just kicking the can down the road because there's some things that you really wanna be able to standardize across your entire fleet, but some things can't hear you. But there are some things that you do want to, uh, have like special snowflakes.

So the way we are tackling this problem is we are saying that the policies, the configurations of your workloads should be unified, like data protection policy doesn't matter whether you're using block workload or file workload or object, workload is still the same thing. How often are you taking snapshots? How long do you wanna keep snapshots?

So all of these things that are common across your protocols should be unified, should be made consistent. Well, I'll this, I mean, the way you do snapshot policies with a block device, especially if it's database will be vastly different than the way you would do it with a file workload. Because rate of change on a block, especially in a SQL, will use a lot more storage.

And you may not take it at the same time. You have to que you have to do all sorts of API stuff you may not be able to do in certain times with file workloads. Take 'em whenever you want, really doesn't matter.

Um, and you don't, you know, the rate of change of a file system is much less. So you typically don't have the same policies with a blocker file. That's Correct.

But it doesn't mean that the language for specifying the protection policy should be different. Oh, I Agree. Yeah.

Yeah. So to get it done, right, So the, how this high level policies are defined and, and implemented, what's gonna differ from protocol to protocol, like when you have a protection policy, it gets provision down into block workloads. But using p groups or protection groups under the cover that has like, uh, questions is really like question group.

But the same language that you use to specify, uh, protection policy for file might translate into like a snapshot directory or snapshot policy on the file system itself. So how it looks at, like when it's provisioned is different. And there are other variables, uh, variations with like the, the, the data itself.

So for example, even within block, like, um, for fiber channel, you can't just move workloads freely between arrays. That's like the switch that you have to think about. Like customers don't all have open zoning.

You can just move an array from one, uh, a workload from one array to the other. So there's gonna be protocol specific additional configurations that have to be done, like figuring out like which host is connected to which arrays in order to be able to, um, manage the zoning. And what Fusion is really trying to do is say, okay, there's all this variation, but it doesn't mean that each of these variations should be captured in such a domain specific language that you can't translate that to other protocol because there's likely a higher level SLA so to speak, that you can define that captures the difference that somebody looking at it or understands.

But when you actually provision and like compile it, it becomes, it goes down to that protocol specific, uh, configuration. So on kind of looking at this broader perspective, mm-hmm. Um, you have Flash Blade has got, um, a file presentation, flash array has a file presentation as assistant admin.

Am I designating whether or not I want it deployed on to flash blade or to flash array, or is Fusion making that decision for me? Or how does that work? So at the end of the day, the user always has the finer choice of where they want to be provisioning the arrays.

But if they want, they can also ask for recommendation. And based on the recommendation, we look at what's required in the preset. If what's required in the preset, it's like buckets.

So that's requiring the object protocol, then we would recommend like flash bit, because flash bit support that and flashlight Is done. Okay. So not to say that this is ai, but what you're doing is I am writing for, what I'm doing is writing a prompt, more or less to say, this is how I want my outcome, this is how I want this to behave.

Come back to me and tell me what you think is best to do here. And then I can, as the admin or the architect decide how I want this to go. It's almost like a prompt.

In fact, we have a demo later on that shows how you can use a language model to do provisioning. Okay. Uh, the subtle differences, this is a precise language for repeatability because the other thing we want with presets is the ability to standardize your workload configuration.

So each time you use a preset, you should get the same workload configuration. The problem with using a prom direct provisioning is there's some variability if language models, like if you ask the same thing, you might not always get the same thing back. Okay.

Yeah. So we prefer if you create presets that states how a workload should be provisioned and have the language model pick the appropriate preset to do the provisioning. And when you say it's a specific language, um, is it something standard like YAML or something like that?

Or is it something unique to Pure? It's unique to Pure, but it's in json. Okay.

So yeah, you can download the preset, you can modify it. We don't think anyone would actually modify the JSON by hand. We have like a gooey visit to walk you through creating a preset.

But if you wanted to, you could modify the JSON directly. Okay. Let's just, uh, run through the demo.

So this is from the point of view of the junior admins, uh, where the presets already been created by the storage architect. So now they're just going into provision a database workload using the preset so they can just log into any array in the fleet. In this case, we have chosen VM dash hacked.

That just happens to be the name of the array. They can see there are two presets that's already been created, a custom one and a prescriptive one both for provision and Oracle database. So now we'll go into the workloads tab, click the plus side to provision new workload, and we're gonna pick the prescriptive, uh, preset.

So here you can see the configuration that was already, uh, defined in the preset. You can see that there's, uh, aura data under storage resources. We want two of them, two gigabyte each, taking hourly snapshots and replicated daily.

There's gonna be an aura log, uh, volume. We want one of them, one gigabyte. Also with hourly snapshots and daily replication.

And below the storage resources, you can see the tags. So every workload that's provision of this preset will be tagged with the tier with the value production. So we know that this is a production workload.

So one of the things that, um, we encourage, uh, our users to do is to actually take their resources, um, to be able to tell like, is this used in production? Is this used, uh, for virtualization? And so on and so forth.

Uh, and a lot of our customers also requested that we allow them to tag with billing ID for chargeback and showback so that when the search admin is provisioning on behalf of like lines of businesses, they know like, which, uh, lines of businesses are actually consuming these resources. So, uh, but right now it's really the burden of the search. I to remember to have to go tag all these resources.

Now this is captured in the preset so that they wouldn't forget. Uh, I can see in the workload text, the production is hard coded as a hard coded value. So any workload that's provision from this preset will get the production tag, but the billing ID takes in the parameter.

And so when you are in this workload provisioning screen, you can see I'm asked to enter the billing ID so that now I won't forget to enter the billing id. And once I've entered the billing id, it'll show up as a tag on the workload. So let's just give it some, uh, billing id.

Maybe it's the, um, person or the department that wanted to provision the database billing id. 1, 2, 3, 4, 1, 2, 4. Next thing we wanna do is, uh, figure out where to place the workload.

So here's what I mean by, you always get a choice for where you wanna be placing a workload. You can either pick via hcme one or VM Hcme two. The reason VM H made three is grayed out is because in the preset, the preset order has defined a storage class of flash array X.

This means that the preset order wants the workload to be on the flash array X. So the only choice available to you are arrays that are of storage class flash array X. And so anything that don't meet this requirement are grayed out.

But you still have free choice for the other two arrays that are flash array X, maybe you don't know which one to pick. So now what you can do, uh, is you can click on get recommendations. Yeah.

So this is just going through what I just said. And click on get recommendations, and you can pick the target that you want to consider. So this is now making an API call to P one.

And based on the, whatever I just described earlier, we'll do some predictive analytics and score the array and things that are above a certain scale. We get the recommended tech things that are below, but still the requirement we get the acceptable tech. So VM PME is recommended.

So let's just create the workload on this array. So now we're just gonna click the create workload, uh, button. And this will start provisioning the resources, configuring them for the workload.

And now that the workload is provisioned, you can see it's here on VM H, you can drill down into it. You can see that it has the workload, text, vehicle production, billing id, one to three, one to four. You can see the two data volumes and the lock volumes.

We provision the two protection groups, one for the hourly snapshot and one for the daily replication. It can configured. So if you were to drill into the, uh, protection group, you can see that it's, uh, replicating correctly to VM H three.

So that's replicating to the flash array c as re requested by the preset author. Uh, and now if you were to go back in and click on the volumes, um, you can see that it's also in the volume group. We use volume group to configure Q os.

You can see the Q os has also been configured, uh, correctly for this volumes. So the entire checklist has now been automated into a few simple clicks by the junior admin to do provisioning. Uh, it's all automatically enforced.

You know, you have peace of mind that is gonna be provisioned and configured correctly. One of the things, this is Kimberly again. 0 was a discussion with the clients about the payback on this.

Um, as product management designing the product, what were you expecting the payback, the customer's value proposition payback to be and for adopting this? So initially we were designing this for MSP customers, like, uh, MSP Like service providers Yeah. Where they would have their own customers making use of their infrastructure.

And we wanna be able to figure out like who's using which resources. Mm-hmm. But then as we start talking to large enterprises, we realized that in large organization, the IT organization behaves almost like a service provider, where like different lines of businesses, different departments, they have credits, and when they're provisioning resources, they are charged to their credit system.

And so what the storage admins really want is a way to be able to like correlate like which resources are used and consumed by which departments. And then they have all these dashboarding and scripts that would like scrape the, uh, metrics and scrape the text to be able to do that correlation and visualization. So just being able to tag a volume with the billing ID is gonna help with all this chargeback and showback processes.

So there's like nothing additional, nothing we have to really deeply integrate with our product, just the ability to tag it because they have all this existing process to do chargeback showback already. Anyway, So Brent, Jim's easy to see, um, this makes sense from sort of a part-time storage administrator longtime Oracle database administrator. Right?

You went there. So I'm just adding to that. Um, what I'm interested in seeing, and I hopefully you're gonna demonstrate this, what happens when they've picked preset A, which would be perfect for say, a data warehousing environment, and then the database configuration changes, someone decides to maybe use that data warehousing environment, which is gonna be primarily read only.

Now there's, uh, an AI component to it, perhaps. Uh, or they decide to just, uh, to save on licensing costs, introduce an OLTP application, right? Something that has a totally different bandwidth mm-hmm.

And IO requirement, right? Uh, I presume we're gonna find out that, so this adjusts for that. That's, that's right.

That's a great question. I don't have the demo for this, but I can talk through it. So, uh, when you use a preset, the provisional workload, you can think of the preset as like a template of what the provision.

Once the workload has been provisioned, you can feel free to make changes to it. You can add new volumes, you can increase the bandwidth, you can change whatever setting you want with it. At the same time, there's gonna be a compliance engine that monitors the preset with the workload.

So when you make changes to it, we can say that, oh wow, the configuration has drifted. Okay. And sometimes this is an intended change.

Sometimes this is an unintended change. So now you can decide, okay, do I want to remediate? Remediate means reapply the configuration from the preset, uh, onto the workload, or you can just leave it as is because this is a intended change.

But sometimes when you are making a change to the workload and you find yourself making changes, the same changes to multiple workloads, maybe it's time to change the preset itself because maybe this OLTP thing is the new way of provisioning, uh, databases. So okay, let's change the preset. And once you have changed the preset, reapply it to all workloads that would use to use these presets.

So now it's much easier to propagate change. It's also a more rigorous way to propagate change. Yeah.

Okay. So question. Um, one decades record announced myself before.

So, um, you brought up MSPs. I think, uh, this would be of great use to that. Obviously that implies multi-tenancy.

So you have presets for workloads. Mm-hmm. Uh, for OLTP databases, whatever, DSS databases, file stores, whatever.

Um, if I'm an MSP, um, I got a new customer, I create a new tenant. Yeah. Obviously multi-tenancy within the arrays that are underneath this is handled a little differently across the arrays.

That's right. So I'm assuming this manages, does, does this manage the multi-tenancy within those arrays and create a tenant that would then get a set of presets, kind of another hierarchy of, of presets or presets so I can deploy another customer with a set of, uh, ready to go templates? That's correct.

So, uh, I'm not sure whether you are alluding to this thing called realm because you already know about it, but, um, I know nothing. Okay. So impurity, we have this new feature called realms to do realms per array, realms to do per array multitenancy.

So you can create a realm, you can designate a realm admin and say, this are all the resources that you have access to. So the resources in the realm, but realms are array specific. A realm group would span multiple arrays.

So maybe Pepsi might be given realms in array A, a B array C it forms a realm group. So the entire realm group can be handed to Pepsi, and Fusion will help manage the realm group. So a realm group would have a certain set of policies and presets that's, that's available to it.

So you can create like a, maybe a database preset for Pepsi and put it into their realm group so that a Pepsi admin can go in there. They can use that preset for any of the realms that they have access to. So if you are like the infrastructure admin, you see the arrays and you see a fleet, if you are a realm admin, you would see realms and the realm group.

So it's the same two layer hierarchy mm-hmm. Things that are physical and things, that's a logical grouping of all of them. And this is part of Fusion two.

So realms is part of purity. It's not technically part of Fusion, but realm groups is really an integration between fusion and realms. Okay.

So, but Fusion is the one that's gonna manage all the different arrays in the cloud and stuff like that. So as a multi-tenant MSP manager, I want to, I'm speaking in product manager terms. Mm-hmm.

I want the, the ability to create a new tenant based on a template. Um, you know, given a choice across all these different array, like whether it's cloud or here or there, right? Because I have all this stuff already and I wanna create a multi-tenant secure device across all of these different things that fusion's managing.

Does Fusion have the multi-tenancy? I see what you're asking. So, uh, the concept of, uh, objective-based, outcome-based management is something that Fusion is doing.

And this is really a workload preset. It's allowing to right specify the objective for a workload. This provision, there's gonna be other kinds of presets we're gonna create in future as well.

Okay. There's gonna be array presets that allows you to specify how an array should be configured. There's gonna be realm presets that will specify how a new tenant should be onboarded and what are all the different permissions and users and, uh, allocations that have to be created for each new tenant.

So like an MSP can just use a realm preset each time a new tenant onboards to create like all the necessary realms and resources for their tenant. So yes, uh, fusion is really going after this thing called outcome based, objective based management. So anyway, there's, uh, multiple use cases for presets.

Uh, the scenario I just explained, uh, where there's like a storage architect and unit admins, and you wanna qualify the, uh, guidelines into, uh, something that can be automated. That's one use case of presets. MSP is another use case.

The other use case is on standardization. So even if you are a storage admin that's doing all the provisioning yourself presets can still really help because you're not going to each array and having to look up your run book and configuring the resources one at a time. It allows you to standardize the configuration so that it's consistent across all your deployments.

Um, the other use case is, uh, the provider consumer separation, uh, where the consumer itself might not be human. So the MSP use case, maybe the consumer is a human, but imagine the, uh, consumer is like a vSphere plugin. So you could, for example, uh, give like the vSphere plugin, uh, preset to deploy VMFS data store.

So essentially this is empowering the storage architect or the storage admin to be able to use presets as sort of way to like publish storage services. They can say like, okay, this is like my goal, uh, VDI, uh, service. This is like my bronze VDI service, the VMFS, uh, data store.

You can pick either one of them to, uh, use. And, um, and the, the, the preset is really like a way for storage admins to be able to publish storage services for third party integration. And if the third party integration itself is a language model, you can see some really cool things happening.

So, uh, just a quick intro. We have built an MCP server on top of Fusion. And MCP server, roughly speaking is like a API gateway, but for AI agents, it advertisers the capabilities that the underlying platform, uh, supports.

So we are just gonna be using the MCP server to tell the language model that, Hey, we have this thing called a preset, please try to use it. Okay. So this demo will go by really quickly.

Uh, what we are doing is just using the language model, ask it very high level, say make me a five terabyte machine learning training volume. And if the language model doesn't know better, it would try to figure out what are all the volumes and configurations associated with a machine learning workload. But with presets, all it's gonna do is just list the presets as available.

And it turns out the social admin have already created a preset called, uh, ML analytics. So that looks like a good fit. And it's just gonna pick that.

So once it picks the preset, the next thing it's gonna do is gonna figure out which array to provision the workload on. So it's gonna get a recommendation. And this case, uh, P one returns with D array X 12.

So now we know which array, which preset to use. The language model is just gonna invoke that task to provision the workload on that array. And in parallel, it's gonna set up the Grafana dashboard.

It's gonna set up the host, configure the host to be able to perform iOS on it. And it's also gonna periodically, uh, whole the task to, to see if the provisioning is done. Okay.

Uh, The task is still in progress and now it's done. So it gives you a summary of what's done, provision, the ML training volume based on the preset. You can see that it has, uh, four hour snapshot acing replication, compression all configured.

Like if without preset, all of this would have to be trained in the language model. But because these are all configured into the preset, the language model can just use it. And not only that, because it's in the preset, it's repeatable.

So each time you ask for a machine learning training, uh, workload, you always get all this configuration configured because it's in the preset, it's repeatable. So is this going against pure in the cloud or is this actually an on, is this doing something OnPrem or? This is actually running on pure storage cloud.

Okay. So, but you would need to, Okay. But you could run it on your array.

It doesn't, the, the fleet interface that Fusion gives you abstracts away where the array actually is. So you could have a actual flash array of flashlight in your fleet. In this case, we had a pure storage cloud in the fleet.

So it's just the EPS is just being directed to pure storage cloud. So going back to one of your premises in the very beginning, is this, um, this available to the dark cloud pe, dark, dark site People? It is.

Okay. Okay. In the interest of time, let's just, uh, go for the recap.

Um, so the things that Fusion want to achieve is very simple. We don't want storage admin to have to manage individual resources. We really want to transform the storage admin into data admins to be thinking about what requirements, what outcomes, in fact, like what SLAs do they want on their data sets.

And they can use Infusion can use this outcomes to automate towards that outcome. And just like sles, this is not a one-off thing. The SLES will be attached to the dataset for the lifetime of the dataset, so that if requirements change, you can just update the SES and Fusion would automate towards remediating it.

Uh, we also don't want search enemy to be thinking about managing the infrastructure. So they should be treating their arrays as like a pool of storage, array config, workload config. They should all be managed as policies.

And so you could have flash arrays or flash bases or pure storage cloud. You could have heterogeneous, heterogeneous feet, but what you have in your feet should be determined by what underlying capabilities you need. And they should all be managed the same consistent management paradigm at the top.

And workloads can, um, rebalance across race in the fleet, non-disruptively in the same protocol. So manage your data, not your storage.