Enterprise Storage for the Cloud – Simplify, Scale, and Save with Pure Storage

All right, so thanks again. Um, so now we're gonna kind of continue through Pure Storage Cloud. Um, and this is really your enterprise grades.

Oh, so David Staman, uh, technical Director for Product Introduction in Cloud. Um, so now we're really gonna focus on enterprise storage for the cloud. Um, and really what you'll kind of see here is an update to our overall portfolio of what we're doing.

There's a, a paradigm shift of what we're seeing here. Again, there might be some forward looking statements, things that are available today as ga, but also things that we're looking to investigate and broaden within our portfolio as well. And so when we really think about this hybrid cloud is this new reality customers and more are moving towards the cloud, whether it's changes to virtualization licensing, whether it's modernization efforts, it's not necessarily Cloud first anymore, it's cloud preferred.

Trying to understand how do these workloads continually do this and how do we actually shift that data to make sure it's available anywhere we need it. So one of the things we've done recently here at Accelerate back in August was actually announced our new portfolio for our cloud services. It's now Pure Storage Cloud.

You formally might have known a product that we had as cloud block store that has been rebranded to what we're being called Pure Storage Cloud dedicated. One of the key points here is Block is no longer in its name. It's part of this unified experience.

That means we will eventually have the ability to provide more services across the single control plane. We've also ga our Pure Storage Cloud Azure Native Service. This is something that we have been working on for a few years, and I'll be talking about what are some of the main differences and how does this differentiate us and how does this ultimately change the service?

And then we'll really talk about some of the managed services that we're continuing to include. So customers are looking for these hosted stacks, whether it's in a hyperscaler such as Azure VMware solution or the Elastic VMware service. But then there's also the cloud adjacent at the Edge, whether it's Outpost or some of these other services.

And the key point here is this still unifies that experience. That means whether customers are using our Evergreen one license or our CapEx based purchase, it all runs purity. It's all managed through Pure one.

It's this single unified data experience that is available to provide as a service, again, blocked today, file an object, you never know. Um, but it's either offered as this fully managed native experience or it's a build your own approach that gives you a lot more flexibility today and it's available in AWS as well as Azure. So question on this, Kimberly again.

Um, the fully managed service, is that managed and sold by VMware Azure, Amazon Sequent on the system? Or is that managed by Pure Storage and sold by you on the cloud? Yeah, so the managed services are Azure's and Amazon's managed service.

However, we're gonna talk about some of the use cases, why customers actually need an external storage approach to be able to help augment those managed services. So I'm transacting through Azure. Yeah, I'm transacting through a Amazon.

Yep. They take all the SLA problems, they take all of that stuff For the actual Azure VMware solution and the A-A-W-S-E-V-S service? Yeah, they do.

When it comes to the storage, depending on whether it's the dedicated or the Azure Native Service, pure is ultimately going to take the SLA and the responsibility for that, especially in the, the native service in the dedicated service, it's a shared responsibility model. The customer is buying a license from us. Mm-hmm.

But they're delivering it in their own infrastructure since it's in their own infrastructure. Pure doesn't, can't just say, go to Microsoft and say, tell me everything about customer and let me handle a support case. It's kind of a shared responsibility model that if it's a purity level item, pure handles that.

If it's a hyperscaler related issue, they are responsible. So first call goes to the hyperscaler, Um, not necessarily. It's kind of that environment is say you're, you're running a virtualized workload, you have maybe compute, you have storage, and then you have the actual hypervisor.

If you have an issue, you kind of know whether you're gonna call your hardware vendor, whether you're gonna call your software vendor or whether you're gonna call your storage vendor. So with this is, in the majority of cases, if you're having an issue with the actual service itself, you're gonna call the hyperscaler. If you're having an issue with the storage or what seems to be perceived as storage, pure is gonna do that.

If it happens to be a hyperscaler issue, do our best effort to kind of handle that. But then gracefully hand off to the hyperscaler with a shared support model that we have with the Azure Native Service, we have 100% control of the infrastructure and the SLAs, which means it's 100% customer calling peer, and we are handling that end to end. So when customers have shifted to the cloud, um, there was a lot of promises.

There was around cost flexibility. This is elasticity, the accessibility and availability and the security. And a lot of these things were supposed to reduce or eliminate CapEx purchases, spiel to scale workloads up and down, making sure that your data was available whenever it needed it to be.

And as we saw this week, um, it wasn't really, um, and so when you have the security customers are traditionally leveraging security tools that were built for their on-premises environments. When they're shifting this, it's now a completely different model of how this reacts. And so what really happened is that there was actually a rise in cost for some customers because they had scale.

There wasn't really a, a lot of visibility into what they're doing. Um, there's a lot of things that are actually tied from capacity to performance, which means there was actually a lot of over provisioning because that's what you could have. The elasticity kind of happened where you could deploy everything, but you lacked visibility To understand where it was is someone might have deleted a VM but left its disc there.

And the only way you would know that is if you were probably looking at a stale object report. The accessibility and availability required multiple copies of your data. You're relying on someone else to manage your infrastructure and putting the trust into them.

And then with security, it's entirely different. So our goal here is to really change and manage and address a lot of those issues. And so if we think about the way the cloud is, it's a different location with a lot of the similar problems we once had on premises.

There's choices, there's trade-offs, there's sprawl. Um, if we think about each one of the hyperscalers when we're looking at an Azure VM or an a Ws EC2 instance, so we'll just talk about native virtual machines for now. Customers can choose one of six different types of discs.

They have to think about, well, do I need capacity? Do I need something that has high throughput? Do I need something that has high iops?

Do I have something that has low latency? What does that disc actually include? Can I do multi attach?

Can I resize it without powering off the vm? Can I back it up? And they kind of build this feature matrix that says I might have one VM that has multiple types of discs.

So databases are everywhere. Um, we kind of mentioned about this earlier, if we think about this, and a standard database has roughly five different types of disk. You have your operating system, you have your database, uh, log or your database files, your log files, your tempdb, and then your backup.

And if you think about the personality of each one of these volumes, they're different. But also what the cloud can actually provide to you is also different as well. So if you think about an operating system disc, if you think about those six different types of discs that Azure can provide to you, really only two or three can actually be used as an operating system disc.

So you don't really need performance, you don't need anything special. So let's go with a standard SSD. You then think about your database file.

I need it to be very fast. I need it to be low latency. I need to be able to provision IOPS independent.

And I might be using a cluster, so maybe I need multi attach, so I'm gonna use an ultra SSD. You think about logs, well, I need it to be fast, but not as low latency as a ultra SSD and I need some other functionality. So let's go ahead and use that premium V two for my logs.

Your tempdb comes around and says, I'm using a storage optimized instance. It comes with an ephemeral disc. It's extremely fast.

Tempdb doesn't need to be ephemeral. Let's use that built-in disc and optimize that because it just works and it works very well. And then when you think about your backup volume, premium SSD works perfect.

You need an eight terabyte disc, you need the 7,500 IOPS that it comes with. It's perfect. But when you think about this at scale, even when doing it via policy, their sprawl, everything changes.

What happens when Azure comes out with a premium V three or an Ultra V two or a standard V two, you're responsible for migrating all of that data. And this story isn't just specific to Azure. The same exact things happens with AWS.

And again, this is an example of one workload. What happens when you have hundreds or thousands of VMs? It's that visibility and management that ultimately helps guide you.

So how do we fix that? One of the benefits of Pure is again, that unified data plane. We have the exact same features in the cloud that we also have on on premises.

So we have the ability to deliver our data reduction, whether it's then provisioning, dedupe and compression. We have our replication that we'll dive into that gives customers capabilities that aren't available in the cloud. Synchronous replication, continuous replication, periodic replication, but even offload to object storage as well.

We have built in high availability, double data at rest encryption and our best in class snapshots. And so customers who are traditionally managing these environments with they're using fusion doesn't really matter if they're managing it on-prem, in the edge, in the cloud, all of these same capabilities are available to them. And that's really this huge differentiator because again, Brett talked about this pure fusion, it's embedded into purity.

There's no additional licensing, there's no additional control. It doesn't break existing integrations. It improves and simplifies this overall experience.

So again, it doesn't matter if you have a flash rate, doesn't matter if you have a flash blade, doesn't matter if you have pure storage cloud dedicated. What happens when we now ex allow this with Pure storage cloud Azure native? It's unifying that example, that fleet that again, manage everything the exact same way.

Change your pretests to say, I need it to be in Azure and availability zone one. And it's non-prod. It can handle all of that placement and creation for you.

So you're doing it the exact same way. And this is this huge differentiator. So what are the benefits up here?

The number one use case we see with customers is a finops use case. What can we do to provide cost efficiency? Because sometimes they work with their partners, they work with stuff, and they're like, well, we don't need the performance of an ultra, let's go to a premium.

They go to a premium says, that's still too much, let's go down to standard. And then they get to standard and realize didn't work, I need to do something else. And so one of the things with cloud products, whether it's storage or whether it's these managed services, performance and capacity are bundled.

They need to scale together. And that results in over provisioning. So how do we fix that?

A-V-S-E-V-S is that number one use case where we see this over bundling and over provisioning. Um, storage is really much more cost effective. We think about this example of a customer.

They're using a a managed service and that is bundled with a three to four node minimum. And it includes compute, memory and storage. So if say a customer had roughly a hundred terabytes of needs and you are using a traditional storage, say they are 10 terabytes each, you would need 10 AV S nodes.

Even if you only needed a very, very small amount of compute and memory. What happens if we can optimize that, if they're using pure storage cloud with either a VS or EVS, you can right size your storage, say, I only need that base three minimum that comes with 30 terabytes of storage. Let's go ahead and put that other 70 terabytes on pure storage cloud.

Or maybe I have workloads that need to be on a local storage and don't need fusion or any of those enterprise features. Maybe they're test dev, maybe they're certain systems those can stay on the actual a VS storage and then you'll use the pure storage cloud for everything you actually need. It really helps rightsize this experience.

So the data reduction is critical. Data reduction doesn't exist in the cloud. And we actually had a customer that kind of went through this scenario where they realized for every one petabyte of data they stored on Pure Storage Cloud dedicated, they were actually seeing a million dollars in savings.

And so data reduction is key. A lot of our customers, we say average four five to one, they're actually getting more because they're expanding on the use cases. They're, they're seeing things where it really makes sense.

I'm gonna get into kind of a test dev analytics use case, but when you have multiple copies of your data, um, by being able to de-dupe and compress that and store it more efficiently, you're reducing that sprawl and applying all of these space saving efficiencies. So one of the other big ones is obviously the capacity is pretty straightforward. The next one that a lot of people take for granted is performance.

Um, you mentioned data warehousing earlier. Data warehousing. You might be running workloads for two hours at a time to do these bulk uploads or do these data analysis.

If you're doing it from nine to 12, you need a hundred percent performance and you're provisioning that for 24 hours of the day. If you have another workload that runs from seven to nine, again, you're provisioning that all the time. Because native cloud storage is not elastic.

It doesn't scale instantly in on demand. Whereas with pure, you have the array available to you so that any workload needs to run data. It has the ability to use all of the performance available to it and optimize it.

We also coalesce our right iOS, which means what happens if we have two systems that are writing data at the exact same time, we'll actually deduplicate that data down to the back end. And so instead of having two workloads writing one gig each, we actually just might write one gig, one gig permanently. And so what we're actually sending down to our backend is a lot more efficiently, just like we're doing from a capacity perspective.

So there's a lot of kind of hidden benefits that sometimes we take for granted, as well as we can either provide limits or guarantees around QOS, you can apply those via workload policies and presets and say, Hey, this workload will always have this minimum or this workload will always have this limit. David, operationally, how does this work? Because when you provision a vm Yep.

You, uh, specify storage. Yep. So are you saying that if you sub are subscribing to one of these pure services in Azure, let's say, um, you are, um, you are more or less provisioning a a a port into the VM or something along those lines rather than a a a, you know, a virtual disc?

Yeah. So where we are today for VM based workloads, um, we are either in guest or in guest NVME over TCP. Um, and again, at some point you never know, we might have SMB and NFS.

And so the connectivity of that is you will provision the volume on the pure storage cloud array, and then either through automation, manual connectivity, or whatever workload be bicep, Ansible, Terraform, Python, PowerShell, et cetera, the connectivity to that workload will occur. So It acts like a NAS and you need to make sure you have the networking service and the rout. Is that, is That what you're saying?

Yeah. So we're staying in the cloud. So we're gonna be deployed within the customer's vnet or VP seats.

Um, if they're having like a hub and spoke or an Azure landing zone model, we can adapt to that. So again, it's gonna be similar to other external based storage where there will need to be that can connectivity. Think about it as we're, we're staying in the cloud where we're pulling together all these resources and there's nothing physical.

It's not like we have a flash race sitting in. No, No. Fair enough.

But is, is the networking service or the cost of the networking service is that embedded? There's no cost to it because we're sitting in the customer's environment, which means it's not traversing availability zone, it's not traversing peers. And so it's free, The instances themselves will have higher speed networks.

So the it's it's embedded in the instance cost of the Exactly. And that's actually, and that's actually one of the other benefits. So when we think about compute, traditionally if you need a whole lot of performance or you wanna use an ultra SSD, you need a specific Azure or AWS instance type.

When you use this, we don't really care what instance you're using as long as as a network adapter, if you need a gig of throughput, make sure it has a gig. Nick, if you need 10 gigs of throughput, make sure it has a 10 gig nick. It's now providing a lot of optionality for you to be able to kind of handle that.

But to the networking point, there's actually a lot of savings. I always kind of call egress and ingress like the silent killer because you don't know they're there until you get your bill at the end of the month. But what happens if you're doing disaster recovery or you're replicating across zones or across regions, um, it can be very expensive.

And so if you think about roughly a hundred terabyte workload, most clouds for inner region traffic, it's 4 cents per gig. So that can get very expensive. You send a hundred terabytes, you send a hundred terabytes, that might take you 10 days.

If you use pure and you're using our built-in replication, we are only replicating the unique data. So if you're getting a four to one data reduction, we're sending 25 terabytes, we're doing it in four x less time. Maybe it takes you two and a half days.

We're sending 25 terabytes, we're dropping that cost. If you're using it for disaster recovery, what happens when you fail back? You had a 10% rate of change.

We're sending two and a half terabytes back now. If you're using other cloud native tools, it's rethinking all of that data, which now might take you 12 and a half days and have to send 125 terabytes back. So there's a lot of benefits to the platform from a cost perspective outside of just capacity and performance.

Actually, you're bring up a very good point. So let's say you're using cloud storage, the pure cloud storage up in, you know, in a, in a, in a region mm-hmm. In Amazon or a or Azure.

And disaster happens. Okay? Yep.

Um, and and when disaster happens, it means like, okay, I've actually lost the story. Yeah. Now it, now normally you'd actually have to recur.

You have to re-baseline the whole thing. So all a hundred terabytes is going up and that's fine. Maybe it can compress on the way up, I don't know mm-hmm.

On a baseline then maybe you get two to one instead of four to one. Yeah. But is there the capability of using, let's say if you're on Amazon, can you snapshot the pure instances, um, to EC2 because running an AC two Yeah.

Can you snapshot that into S3 so that you can protect yourself against a full blown loss of everything? Yeah. Um, So with our solution, I, I kind of have this slide pulled up here, but we'll jump to the next one here.

Um, is app here we have kind of, when you think about five ways of protect your data, what you're kind of looking at is around cloud snap offload. Yeah. Is we can actually, so if we use, so really based off the requirements you have, whether it's zero RPO zero RTO or say a 24 hour RTO and a four hour r po, take your pick.

This is all inclusive up here. So if a customer wants to actually do synchronous replication across two arrays, have high availability within a region, go synchronous long distance, go active DR or periodic or if you want that archive outside region, outside zone, you can use clouds snapp that can offload to blob S3 or S3 compatible storage. Whether it's like a wasabi or, or something else or a flash blade.

And you get all of these benefits and you don't have to pick one or the other. You can do, and most of the support both fan in as well as fan out, that provides the ability that customers can choose what they want. And again, with Fusion, build that into their possibility that says maybe I want to continuously replicate data.

Maybe I wanna snapshot it once a day and then maybe offload that snapshot again. Policy driven, you say what you need and it all happens magically. Well, I, I guess my, my question about cloud snap 'cause it's a very interesting concept is if I had the full, full disaster and I'm, and I'm, let's say I'm going out Yep.

A real array off-prem. Mm-hmm. Um, and I can restore from clouds snap in the cloud Yeah.

To a point that's say, you know, a day bef a day before and I'm, I'm now changing, I, I got my 5% rate to change on, on-prem mm-hmm. Where I'm running my in in disaster mode. Yeah.

Um, if I've lost everything and I restored a cloud snap, is it recording? It is, is it restoring everything including the local snapshots within the pure, so I can only do a uh, uh, a re not a re-baseline, but just get from back. Does it restore that whole set of snapshots as well?

Yeah. So think about it as it'll you, those volumes will be part of a protection group and we offload that protection group. So when you need to recover that data, you can pull it down to any array running any pure array running, uh, so either flash array or pure storage cloud.

And when you pull down that snapshot, it knows the blocks that are part of that. So if some data is already on the array, it's only pulling the data, it needs to hydrate that. So if 25% of that data existed and only 75% in the cloud, it's only pulling down the 75% it needs to actually hydrate.

No, no, no. I get that. I'm, I'm, I'm pretending I'm creating the cloud again from scratch Yeah.

From the cloud snap because it's all gone. Yep. I'm completely rehydrating that thing and now I want to, I I've now changed last couple of hours on prem.

Yeah. I just wanna, I just wanna send those changes back. That's possible.

Yeah. That's pretty cool. But that's, that's more than just a resiliency option.

That's also if I want to do things in the cloud with sets of data that I, that let's say I wanna do an operation with a large set of data that I I, it's cheaper for me to have it in say S3 i a Yeah. Or, or some sort of S3 single zone or you know, single, uh, you know, lower redundancy Yeah. From for savings.

'cause it is more expensive to run it in the C two live all the time. Yeah. Bring it that.

And then when I want to use that for operations for say batch analytics classification, you know, take your pick. Mm-hmm. I can rehydrate that data, just make a little update and now I can go do that stuff in the cloud and then shut it down when I'm done again.

And even if my base at home now maybe I'm running on array is production. Mm-hmm. Right.

It allows me to do things in the cloud outside of my own product. You can get to do some pretty cool things with this technology. Yeah.

It's actually really cool. So we actually have a customer looking at using Cloud Snap, um, around an isolated recovery environment is they have two air gapped environments, but they need to get the data from one place to another. So in their production they're offloading it to Cloud Snap.

And again, it's in a completely unnamed tenant, unnamed subscription doesn't even really matter what cloud it's in, when they need to recover it. They're automating the, pulling down to that other environment and continually doing this. So again, think about it here as you're offloading that data to that bucket and you can either pull it back down to where it came or to any array running purity or if you're not even in that file, to you point stand up in AWS stand up in Azure, stand up in all of those environments.

Um, I'm gonna kinda jump it forward here for a second. Um, and so one of the biggest differences of kind of what we're doing and really this next evolution is what we're doing with Pure Storage Cloud Azure native. It's really changing the way we have traditionally thought about the storage.

The first use case that we went GA with was for Azure VMware solution. And there's kind of a, a few reasons, right? Um, majority of customers in the cloud are looking at some of these managed services.

It's one of the easiest ways to quickly migrate. Um, and it's really one of the ones that has the biggest need for external storage. The, um, data protection, the innovation and all of that built in.

The key point of the Azure Native Service is, as it says, it's Azure native. Um, it actually uses something which Azure calls Azure native integrations that allows third parties like Pure Storage to actually build and operate a native service that looks and OP acts and operates like a first party service. And one of the key points here is you, we were kind of talking about this earlier, what happens when you say I need an array?

When you're using Pure Storage Cloud dedicated, you kind of have to know do I need one model or another? Do I put it here, do I put it there With Pure Storage Cloud, it's storage that evolves with the customers. It's that cloud operating model that says you will deploy a storage pool and you will pay for the capacity you actually consume, obviously with a minimum.

And when you need performance, you will provision how much performance you actually need. So instead of saying how fast are your arrays, the answer is, well how much performance do your workloads need? And we're sizing that holistically.

You can tune it, you can have it on demand, while customers can still reserve particular performance if they need to burst, they can do that instantaneously and independently of any other capacity under the storage. And where this is key is really think about what this looks like at a high level. If you kind of equate this to sort of what we're doing on prem, we have what we call the Pure Storage Cloud service for a VS.

That is the billing construct. That is where a customer will choose either a public plan or a private plan. Um, that'll be done either directly through Pure, directly through Microsoft or directly with their partner.

That is essentially, as you would equate the Evergreen one. That's how they know how much they're paying for how long, and at what term. Within that there's the storage pool that gets created.

Um, this is essentially the same instance within that storage pool. We will create a container, a storage container, and within that storage container, we'll actually store the volumes and the snapshots for the customers. And this will be done and injected securely into the customer's environment.

So if we look at what this happens, if you think about an old way of deploying a pure storage cloud dedicated array, you might have had pre-reqs, you might have had sizing, you might have had to have firewalls and networking and security policies and NS gs and then deploy VMs for management. With the Pure Storage Cloud fully managed service, it's easy. You go to the Azure portal and you enable the resource provider.

You search for Azure Native and say, I want this service in this region with this name, with this pricing plan. Whether again it was the public or the private. You deploy your storage pool, you say, I want it to be called this in this availability zone and it's attached to this vnet.

You then go to the Azure portal and say, here's my a VS environments, let's go ahead and choose the dropdown. And it's automatically configured, no external management required. And then one of the biggest differences is we'll actually register our vSphere client plugin to the managed instance in A VS, which means that customers are no longer managing storage into different places.

We're allowing them to manage their data stores, manage their snapshots, manage everything in that, in that portal, and actually have the ability to do instant VM recovery. Say their VM gets corrupted or you need to do copy. All of those built-in plugin workflows really help and handle that.

And how we actually dive into this is again, we'll look at the a quick video, um, is that we have the ability that a customer will go in and create that parent resource. This is where you'll go into the Azure portal and search for Azure Native Pure Storage. And within this there will be the plan.

You'll have your billing and you'll specify where it's actually being deployed to, just like you would with any other Azure Native Service. The next thing a customer would do is go in and actually create that storage bowl. So we recommend a minimum of a slash 28, but the only prerequisite a customer actually has to do is delegate that subnet to the Pure Storage Block service that essentially tells our service, Hey, you can deploy your service over here and you can inject the network over here.

And that is that key point because when a customer goes in and actually creates that storage pool, we actually place the network adapters for that service in the customer's environment in their own vnet. So it's extremely secure and allows 'em to actually apply their own policies against that and limit what can actually happen. If they're using a VS, obviously you're gonna wanna make sure we're pinning it to a specific availability zone, but we allow them to pick the performance they actually need and scale that up and down and again, choose where they ultimately want that deployed.

Lastly, the benefit here is there's no longer a management VM to handle connectivity. If you go to the storage pool, you can say Connect my a VS environment. We will ask you, well what subscription that you have access to does that live in?

And then go ahead and choose that AAV S resource. Once you do that dropdown, we will not only register that vSphere client plugin, but we will handle all of the plumbing for you around enabling the as the adapters, making sure M PIO is configured, making sure all of those settings are actually there. And again, since this is a native service, all of your monitoring, all of your management gets rolled up, customer doesn't need to know how to manage purity.

They can see how much capacity they have, how much snapshots they're using, what is their current data reduction, where is it deployed, and ultimately monitor that through a very familiar experience. So David, on the back end, is this leveraging V Vaults at all or is it just pure VMFS on? I knew that was gonna come up.

Um, so right now this has been a service that we've been developing with Microsoft for many, many years. So before Broadcom decides to kill V Vault. Yes.

So right now we are using granular storage with V Vaults. We are creating a storage container. But with it being a service and us using our plugin, we're already working on AVIA or on VMFS support.

And it's not gonna require any connectivity. All it's gonna do is that when a customer comes into our plugin and creates a data store, they're now gonna have a choice. Do you want VMFS or do you want V Vaults?

And it's simple to those customers and all of those workflows will follow them. And the plan to deprecate v vaults over time Gonna be ultimately when VMware wants to. Right.

1. So if you think about a lot of the managed stacks, it might be, we might still have a good two years approach. There's still a lot of really good use cases for V Vault, so we don't want to kill them proactively 'cause we're still getting customers asking for them.

Well thanks. Thanks for that Ken. Um, and then lastly, this really allows the customer to manage that entire experience from vCenter.

But how would a customer vaccine migrate to this? It's easy because it is a data store within the AV S environment. It's just a storage motion.

So it doesn't matter if a customer is using Pure Storage Cloud dedicated today and they wanna migrate to the Azure Native Service. Doesn't matter if customers using vsan or another external storage, moving to Pure is as simple as a storage vMotion and it makes it extremely easy. No replatforming, no changing, just inherit all of our benefits.

But we're not just gonna stop there being a native service. It allows us to create our own resource provider within Azure. Every other service within Azure has their own resource providers.

So think about storage, think about VMs, think about a KS, sql, et cetera. And what that actually allows us to do is really tie in and actually have native integration with these services. Which means anything that Azure builds for their infrastructure as code, we automatically inherit.

So why not use Bicep or Terraform or all of these toolings to go ahead and manage the creation? And again, we're giving customer choice. While you can do this and provision in the management of everything with Fusion, some of the things are still at the cloud level that will ultimately integrate with.

But as we continue to expand this, we're looking at other things, right? So we're looking at a preview of what would this actually look like if we bring Azure VM support to customers? Because again, one of the biggest pain points is actually deploying everything.

But then how do you handle connectivity? What if we could actually deploy a actual native service to a customer that's completely in Azure? But then instead of having them manually configure all of the settings and MPIO end to end, they could actually run a VM extension and say, here are my targets configure everything for me.

There's no longer custom script development and everything and we have the ability to bring this out 'cause we're now native, we can tie this in, we can bring this to other native services. So after Azure VM support, who knows what's next. Maybe we're gonna look at containerization with ABRA Kubernetes.

Maybe we're gonna look at past services. You never know we're a native service. We get to integrate with other resource providers.

So again, feel free to learn more about Pure Storage Cloud. Look at what we're doing with Fusion, look at what we're doing with our entire portfolio. And we really thank you for joining us here today.

Um, at Cloud Field Day.