Storage Unpacked Podcast - Storage Unpacked 257 – The Future of Data Storage in the Enterprise (Sponsored)

Episode Date: April 26, 2024

In this sponsored episode, Chris talks to Fred Lherault and Larry Touchette from Pure Storage on the evolution of storage in the enterprise and the impacts on storage administration.

This is Storage Unpacked. Subscribe at StorageUnpacked.com. This is Chris Evans recording a Storage Unpacked podcast. I'm here today with two friends from Pure Storage. I've got Larry and Fred. Guys, how are you doing? Good. How's it going, Chris? Yeah, doing great. Thank you. Thank you for having us. Oh, no worries. I think we're going to have a really good discussion today. But before we sort of dive into doing that, why don't you both introduce yourself? Fred, why don't you start? Sure. So I'm Fred Leroux. I'm one of the field CTO for Pure Storage MEA.

I've been at Pure for about 11 years. My job is I work with some of our strategy customers to make sure that they can adopt our solutions, but then also capture their feedback, bring it to our product teams to make sure that we build the products that they need. Great. And Larry? Hey, guys. So my name is Larry Touchet. I am a product manager here at Pure. These days, I'm focused on our Fusion product, but I started at Pure almost 10 years ago. I'm in my 10th year. I hired in as a technical marketing engineer and moved into product management. I launched our ActiveCluster product, which we're pretty proud of here at Pure. Among other things, I worked on our first cross chassis NDU from the

400 series to the FlashRay M when we had to come up with clever ways to move a running system with downtime across different chassis. So that was a fun project to work on. And then various other things throughout the product. There's little nits and things here and there in the product that you may or may not like some of them could be my fault or my responsibility so a few little nuanced things that i think it's neat to see how you can influence products when you work for a vendor like that but yeah it's been a fun 10 years fred and i've known each other for a long time here at pure both getting some gray hairs and my eyesight's going. Excellent. Okay, brilliant. Thank you for that. And I do remember the 400 and I do remember

that very early sort of upgrade. It's funny, isn't it, to think that, you know, since that product release, that's one of the things that's been possible is that upgrade process, which is one of the features we'll talk about as we get into this discussion today. Now, we're going to talk about the future of storage management. This is, I guess, a topic that is probably close to my heart because it's a task that I've done for, well, I probably did it for about 20 years maybe, across mainframe and open systems. So I've sort of been heavily involved in this,

but not in probably the last 10 years. But obviously, this is an area that's changed significantly over the last 30 years. And it's changed for a lot of reasons. And I think the first thing I'd like to sort of dig down into is just what those long-term trends we've seen in the industry have been and why they are influencing the current state of storage management now. So who'd like to pick that one up and give us some sort of background as to what's actually happened in the industry?

Well, I can get us started here. So, and then Larry, if you've got something to add, feel free to interrupt. So, you know, as there's a number of elements indeed, the first one is like, you know, capacity requirements keep increasing, right? So some of the numbers we hear about is in the order of 25%

to 30% more storage required every year, and it keeps going up. We don't know many customers that need less data every year. At the same time, the type of data has changed. There's that proliferation of unstructured data versus structured data. A lot of that is being driven these days by AI, but not just, right? There's all of the modern analytics type of use cases and a lot of data being created around video and so on. That's part of that. That data, while it's being diversified in terms of type, it's also diversified in terms of where it lives. So now we've got data on-prem in the cloud, in multiple clouds very often, sometimes in our data center, in someone else's data centers. We've got some security concerns. There's, you know, every week we hear about some data security

challenges that people care, you know, that are impacting that market. So securing data is more and more important. But at the same time, there's a clear requirement for, you know, faster, more agile access to resources and access to data and access to storage. So a lot of the users are now used to the speed and the agility of the public cloud, and they expect this everywhere. There's no, you know, like instant is the default requirement. Anything not instant is not good.

At the same time, there's also, there's been some changes, you know, in the way applications are packaged and some of that driven by containerization, which basically creates more and more storage objects for a given application. So we have to handle more storage objects. We have to deliver them instantly. Sometimes those storage objects are going to be created or changed faster than humans can really keep track with them. And then we have to handle them in multiple locations across different clouds and infrastructure. And then on top of this, we've got sustainability challenge. There's not a week where I don't hear from customers that their data centers are full either from capacity or from power point of view so we're trying to do all of these with less power that because we need

to you know save power from AI yeah yeah lots and lots of issues Larry I mean that was a massive list of all sorts of things anything else to add to that the way we hear about what customers are challenged with or at least what I hear from a PM perspective, is you hear different things from different customers. So every customer has been trucking along for years, running their own IT infrastructure, coming up with their own in-house processes for the way they need to do things. Some customers, as they get more mature, will start to look at SaaS offerings for automation or other like third party tools to help them drive and get more efficiencies out of things. But so I typically see what I would call like three kinds of customers. There's customers who aren't really doing any automation yet whatsoever.

And there's customers who are doing a little bit of automation and automating tasks that have become pains for them. And then there's customers that are at really high scale and are trying to automate absolutely everything and as much as they can. But it's curious that you actually see a mix of things. So we have customers with many, many arrays who aren't automating anything yet because the arrays are simple to manage. And they have a team of storage administrators who can handle that, those tasks. And then there's customers who automate absolutely everything because of their their fleet size is very huge. But what happens is it's the scale that your organization is at that drives the kind of automation you're interested in. And so scale could mean you have hundreds of systems, so you're more interested

in automating and maintaining the configuration of the storage system itself. Or it could be that you're running a container-based environment and the scale comes in the pain point of the number of storage objects like file systems or volumes that you have to manage. So you could have a small number of arrays, but a massive amount of configuration churn with like ephemeral volumes being created and deleted on the fly. And even though you don't have that many systems, that kind of thing is unmanageable from a manual perspective. So I find customers with all different kinds of challenges, whether they're small or large. So I no longer make the mistake of just assuming what a customer is going to say their pain points are based on the numbers

of arrays they have, because that's always what we do. Every time I get invited to speak to a customer, I go look up their phone to home data, see how many arrays they have. And over time you realize you have to take a different look. So, okay, let me see how many volumes they have. Okay. You only have, you only have 10 arrays, but you have like 40,000 volumes across the 10 arrays. But then you'll see another environment with 100 arrays and every array only has a few volumes or file systems on it and so you can draw clues as to like what are they doing in that environment and what sort of pains might they have but in the end you just have to ask them and see like what's going on what's their day-to-day pain point okay i mean just as an aside a fun fact from 1996, I worked in an environment where I managed 300 gigabytes,

300 gigabytes of storage. Now, you might say that surely you mean terabytes, and I mean, no, 300 gigabytes. This was 100 2.8 gigabyte mainframe volumes, of which there was no aid, so everyone was at recovery if it failed from backups and everything. And you look at that and think, how could that even be possible when you look at modern systems where we now talk in petabytes?

But of course, that sort of represents the difference that the customer has seen in terms of what they expect from their storage environment. There's a demand for a huge volume of storage now. The cloud has pushed us towards on-demand and just that self-service and being able to think that you can just go and grab it. The idea that we should have to even think

about where that storage is deployed in terms of the hardware is out the window. The customer just wants metrics. So the experience from the customer, I think, is completely different to say where it was maybe 10 years ago when people used to be very much more focused on the actual hardware

that was delivering those resources to them.'s having the the cloud vendors be available we've all just seen this transition i would say in our lifetimes but it hasn't even been in our lifetimes it's just been since we've been professionals working in the industry we've seen these like huge transitions and so a lot of big organizations have, maybe it's a dated term, but there's like the notion of private cloud, but you may just say your private infrastructure. So I still talk to customers all the time who the storage administrators are not allowed to access YouTube from their laptops. So they're not allowed to access certain internet sites and they just don't get access to these kind of things and

the organization's trying to maintain control of the infrastructure and the security and then you have a storage team that's kind of struggling to keep up with the day-to-day tasks of managing and running storage and all the consumers or employees in the inorganic and the organization know that they could just go swipe a credit card and get everything they need from a cloud vendor instantly, like what Fred was saying. And so it started to create this contention between the application owners and users in an organization with the storage teams getting frustrated why they don't get that kind of experience. Because that's how every new application or startup goes today no one buys and

builds a data center or infrastructure or runs things in their garage they're all just going to start their businesses building new apps in the cloud and eventually if they're successful figure out what they're going to keep doing that's some of the pains we're trying to address is to help help storage teams provide their application owners an experience that they won't feel so lacking of some of the speed and efficiencies that you can get in a public cloud. And I think one of the things you said here earlier, Chris, in terms of metrics is very important here.

Indeed, like a lot of the end consumer, that's what the end consumer, the customer or file administrators, that's what they're going to look at and that's what they're going to care about. And now they are more educated in terms of how those various metrics are going to be measured, not just in terms of financial costs, but also even in terms of power efficiency, right? So they're going to be looking at, indeed for a given resource, how much is it going to cost me to get that with my private cloud? And then going to go and compare this and contrast this with public clouds

and very often actually choose depending on a given requirement where that application should live. So that's part of that. And you also mentioned earlier, right? That self-service aspect is, I think also very important. More and more of those customers, of our customers are technical populations themselves.

They don't want to have to ask someone to go and provision infrastructure resources. They just want to click a button or call an API and then have that happen automatically for them. So you do have to, and we'll talk a bit more about this later, but you do have to go and build products that are designed for that self-service aspect, as well as, of course, instant availability. Yeah, I mean, that's one of the areas where I've spent a lot of time when I was working, trying to think about how we actually made that work.

You know, how would you enable people to actually have a decent service catalog that abstracted the hardware and many times we were tripped up not by my fault not my fault isn't the word but by um senior managers not realizing the way that we wanted to build the infrastructure but we were tripped up where we would build something that was still very hardware focused and the customer was like oh well i wanted to do this and i want this i want this platform and we're like you don't need that platform because this new one is cheaper and gives you a better a better service so just ignore the fact that it's you know from vendor x or from vendor e or whatever it happened to be and thankfully i think everybody's moved on from that and i would hope you know larry i think you

were about to jump in and say something but i would hope that that's what customers now think that they they don't need to be as concerned about the hardware aspect as they used to be yeah i was going to mention that um like fred was talking about the way we've built our products here at Pure, and non-disruptive upgrades has always been a big part of it. And the way I think about it is that the longer I've gone in my career, the less things you ask customers about because they just don't make sense to talk about anymore. And one of those things is downtime. And so I remember years ago, you would work with a customer to schedule when can we do

your upgrade and you would expect it to happen on a weekend. And I worked in professional services and spent a lot of time, you know, nights and weekends in data centers copying terabytes of data around. And it was just an expectation that every customer has some period of time, either on a weekend or late in the evening, in the middle of the night, where they can take an outage. Or you'd work with a customer who's on the other side of the globe, and they can take outages during your business day. But it's just not a topic that even comes up anymore. You never, ever suggest to a customer that you need

some downtime to do something it's just no no one wants to hear it even from the smallest to the biggest customers it's just not a thing because like the hyperscalers their clouds don't go down so people just don't want to talk about this stuff anymore and one of the funny things I always think about is like when you look at pure arrays and you, when you talk about the notion of uptime, like six nines or seven nines, what that really means is that many, many customers have 100% uptime. And some customers have a little bit of downtime because it's averaged across our entire install base. And so what that means is there's customers who have had PureArrays running for a decade now with no outage. And they've transformed those from the 400 series to a Flasher AM to an X to an XR2 to an XR3, maybe to an XL. And you can see proof of that. And just when you look at our phone home data like we have xl 170s that are named

like for running an oracle database they're named like aura m20 r1 you know but because that's what the customer named it when they first installed it and now they've got this thing that is three generations different and maybe moved to a different chassis but it still has this old name so like best practices don't give your pure arrays host names that incorporate the model of the array because it's not going to stick. Like your data is going to sit there and be on that thing, but that thing is going to morph and change and last you like a decade or more. Yeah, it's pretty much I think an assumption nowadays

that you should think of the thing as a physical platform that's supporting a virtual array, shall we say, because ultimately the underlying hardware is going to get replaced over time. And if you're going to do it properly, that's all field upgradable. And it should be field upgradable to the extent that that data just exists in perpetuity. Perpetuity, is that the right expression? Yeah. Perpetuity. Perpetuity.

One of those words I was like, how exactly do you pronounce um whereas the well it might be different between uh british and american so i might have just misled you it could be and also um xr2 and xr3 will mean something totally different to uk people by the way i said a story for another day oh they're cars they're cars from the 1990s um so i think yeah i mean that's really interesting. I just wanted to very quickly touch on that idea of the availability as well, because, you know, we used to talk about five nines and all the rest of it. And I think people don't necessarily think

about what it really means and the fact that actually you're averaging. So ultimately you're averaging across potentially tens, hundreds, thousands of customers. And, you know, only if one customer is unlucky enough to have some sort of failure that takes their system down, well, it doesn't mean that the majority, more than the majority, you know,

almost everybody's already getting 100%. And I think that's quite an important sort of aspect to look at. Really, you're targeting 100% in all of those cases. Yep, things are going to happen. Sometimes they're in the system. Sometimes they're outside of those cases. Yep, things are going to happen. Sometimes they're in the system. Sometimes they're outside of the system. But yeah, the goal is never an outage. Yeah, exactly.

So, okay, so customers now got a different expectation. You know, we expect the self-service on demand, high availability, abstraction, all that sort of stuff. So how has this changed the role of the administrator? You know, how has this changed the job of the person who actually has to look after this stuff? It sounds to me like they've got an easy job when you think about it, because now all of the tasks that they used to have of provisioning and stuff,

they've just pushed out to be automated. But actually, I think that might be a little bit generous there. There's still a lot of work to do. Yeah, there is. I'll kick off one idea, Fredred and maybe you could add some more and then it's like um someone still has to do these things right and by these things i mean manage the system and keep them running like security updates software updates it's kind of like um we've been using this analogy internally here at pure with the changes in our own processes

that like imagine the uh formula one uh pit crew you know the car pulls into the into the pit and a whole bunch of people come out and start swapping things around and changing things but imagine doing that without stopping the car and so like the car is rolling down the road you've got to keep all the services running and you want to change the wheels out so you can put more efficient wheels on and things like that and so the storage administrators today i think have a more difficult job because they have to keep the system progressing and maturing and they have to take advantage of new features that the vendor might be rolling out in the next version or they have to update for security patches and doing that without causing downtime is like stressful for them. They need to have the right tools to do it. And so like one of the tools we've

started providing more recently here at Pure is customer driven upgrades that you can just drive on your own from the cloud. So you can schedule them, drive them yourself, get assistance from Pure to help you with them if you want one of the things we do here at pure is try to make sure that customers can easily roll their uh their software version to a new version have some new features in that version of software that they can start to take advantage of like all the while trying to do it without letting the wheels come off while you're while you're going down the track and And I think one of the reasons you need that is because the, so, you know, we spoke about that idea of self-service

and really what it translates to for the administrator is they're moving away from the job of actually doing day-to-day provisioning of resources, right? So instead they're becoming more like product managers or cloud managers. They define services. They are building the tools, the APIs, so that their own customers can go and provision from those services. And then they've got to manage the underlying resource, the underlying fleet of resources.

So in our case, we're talking about storage systems. That has to be fully transparent. When a cloud provider goes and upgrades their underlying storage systems, you don't know about it as a user because that's all abstracted. So indeed, I think it's a prerequisite of moving to that product management type of storage and self-service is the underlying infrastructure has to be transparent, has to be abstracted. I always like to think of it as like a front-end and a back-end task if I'm an administrator. So I've got a set of back-end tasks, my backroom

tasks, which are upgrading, keeping the lights on, keeping it upgraded, making sure I've got enough capacity, making sure the performance is even and working across all my systems. But I've got a front-end set of tasks, I need to be able to present this stuff to the customer, the customer needs to know how they can consume it, they need to know what it looks like in terms of performance and, you know, capability. So as an admin, I'm doing sort of two jobs at once. Now, it seems to me that over the last sort of 20 years, perhaps, that the set of demands we've said about what the customer expects has changed the ability of you to deliver that so for instance doing things like always on or being able to guarantee performance if we were using things like old style raid groups

and all that sort of stuff would be a nightmare to still administer and more and more of those tasks larry i believe you've pushed into your products in order to take that burden off the administrator so for instance in the po products nobody ever talks about rate or protection or performance all of that is managed at the back end the system just delivers and all of those tasks that used to be done have all been taken over by you as a vendor you've absorbed all of that on our behalf yeah Yeah, there's one. I was just talking to a friend this weekend. We were reminiscing about old days when we were in professional services, and I once screwed up adding some new drives to a NetApp system when I worked in PS there. And I forgot to type the command to increase the size

of the RAID group before I added three more drives to the RAID group. And so it put one drive in the existing RAID group and then it made a new RAID group of two. And so the customer got only two thirds of the capacity they expected. And as soon as I saw it happen, I just dropped my head because the shelf was full. There was no more slots to add drives and the sales rep was upset with me. And he wound up throwing a whole new shelf for free at the customer. And I was like, we probably didn't have to give him a whole free shelf. But he was like, you screwed up.

So we had to fix that. And so I'm glad it's like those days are gone. There's no such thing as RAID or managing collections of disks. We never think about that stuff anymore. Yeah, I mean, they're not there for you, but not everybody's gone down that route. And I think when you're looking at differentiating factors between different vendors,

that to me is one of those things that I would think now as a customer, if I was coming to buy in the market, I'd be looking at things like that. That's a, that sort of design flexibility that allows that sort of test to be A, taken away from me and B, the risk to be taken away from me that i can't get it wrong and things like that apply then when it comes to things like on demand you know so i want to add capacity and i want to just increment

that gradually from a business perspective which we're going to go and talk about next if you haven't got the ability to have that granular level of addition if every time i have to put something in it's an entire shelf or two shelves or whatever it happens to be, the cost increment could be quite significant. And that's why I wanted to move on and talk about next is how the business deals with this because as a business,

the demands for capacity are increasing massively. The costs are increasing potentially if the cost decline doesn't come at a quicker rate than the growth rate, then costs are increasing. So there's a design implication from your products, as well as a financial implication that comes from getting that sort of design right. Otherwise, from a business, the costs just escalate. Yeah, that's right.

I mean, so, you know, first of all, there's obviously there's a cost of procuring the infrastructure itself. And that's why if your capacity is growing at 30% per year, you need to keep that under control. But then there's also, of course, the cost of managing it. So for a lot of organizations, traditionally, they've been managing or thinking about this in terms of how many terabytes of storage can I manage with one administrator. And now it used to be, well, gigabytes in your case to terabytes. Now we're now talking petabytes. And we do have some of our customers are managing multiple tens of petabytes with the equivalent of one administrator.

So that's part of it. That's one of the ways you measure that. And if you don't do all of the things that Larry was mentioning in terms of automating, in terms of not having to think about how all of the upgrades or not having to babysit them, then you're just not going to be able

to reach that level of scale. Yeah, funny enough, I would say that looking back, probably only 10 years ago i was probably i used to i used to do some work for a particular vendor and we had a benchmark a score card where we'd go in and rate customers before we actually gave them a recommended upgrade and you know it was obviously um let's call it slightly contrived but it wasn't entirely contrived but i think we used to work at about 250 terabytes and FTE. And that now just seems laughable when we look at the volume of storage we're deploying these days. But at the time, that still seemed quite a lot when you had to consider the physical

architecture of the box. And when the actual design of systems and the deployment of systems and upgrade was still the admin's responsibility that probably wasn't an unreasonable number but it is interesting to see how that's changed but how does that affect the business when they're looking at say their costs so admin people are one side of things but there's a whole aspect around how you actually can deliver technology to the business and allow them to consume it in a different way so for instance if i have to go buy the whole thing that's ridiculously expensive if you had to put the whole thing on the floor and allow us to consume it in a different way. So for instance, if I have to go buy the whole thing, that's ridiculously expensive. If you had to put the whole thing on the floor and allow us to consume it over three years, that would be ridiculously expensive for you capital wise. So there's a, I think there's a design aspect into both the hardware and the software to

monitor this technology that allows you to be financially flexible. That's what I'm trying to get to. Yeah, a hundred percent. And I think that really ties, that's the other side trying to get to yeah 100 uh the and i think that really ties that's the other side of the coin from uh what we've been talking so far is like the flexibility and automation and orchestration and the what customers are building with it at the end of the day is going to be a cloud-like service right and the you create a cloud-like service, you enable self-service and automation, you don't really at that point understand how quickly that's going to grow or not. It

may be growing at 10% per year, it may be growing at 100% per year. Indeed, if you had to procure storage for three years in advance, by that point, it's like, how much capacity do you need? You don't really know. So for a lot of organizations, the way you do that is instead you move away from the sort of traditional CapEx purchasing for the next three, four, five years to more of an on-demand model. And that's something we've seen with Pure. We created years ago something that,

we used to call Pure as a service, and now we call it Evergreen One. And it's really a different way of consuming our platforms where you don't acquire them, they've still belong to Pure, they're installing your data center or consume software in the cloud, but you only pay for what you really use. And I don't mean provision.

You really pay for the real data. You only pay for the real data that you write to the systems so that now you can say, well, if I'm going to build one of those storage cloud or storage as a service offering for my internal users, if it grows slowly, I haven't taken any risk. If it grows quickly, then we, from a pure point of view, we've got SLAs to back that service in terms of how quickly we bring new capacity,

if needed, but also how to sort of availability to sort of match what Larry was talking about, and so on. So that if it starts going at 100% per year, you've got what's required to accommodate it and you always have a buffer of capacity instantly, but you don't have to plan that three, four or five years in advance. So that business and that consumption model, I think is the other side of the coin here. Anything you want to add, Larry? Yeah. The other advantages that customers get when they switch to that kind of model is that as if you're consuming something as a service, then the vendor can update and morph and change and add more functionality to that service for

you over time. So like examples are like the paid power and cooling guarantees, ransomware recovery guarantee service. That was something we added a short time back. And so you can be on this platform consuming and utilizing storage, and then the platform can mature and you're still a subscriber to that thing. And you just get more functionality by being a subscriber. Sometimes people don't bring up in very simple layman's terms why these models make something very simple. And probably the most expedient thing is that when you need new storage, you don't have to go through your internal processes and red tape around cutting a PO, evaluating, proving to leadership that you want to make this purchase, going through the whole

process of waiting for things to happen. And so everything just becomes streamlined. When you procure storage in the traditional way, you have to buy enough to meet your needs for the amount of money that you had to spend right now. And you can never be sure that your requirements aren't going to change. Maybe you need less, maybe you need a lot more. So you often have to over-purchase. This is also true in the way storage provisioning generally happens. So even in an environment where the customer's infrastructure is already set up and you're going into this

consumption and usage mode, the businesses inside of an organization, they can't really tell how much they're going to need. And if the organization is not doing some sort of chargeback showback model, then it's a free for all. Every new project that starts up or every department is just going to ask for the best, fastest storage they can. And you get these like islands of underutilized storage and then other islands of overutilized storage. So consuming storage as a service is a good thing because there's always going to be different models, not models, but different tiers of storage you consume. We have ultra and performance and standard. They have different capacity versus performance characteristics for what kind of

storage you need. And then the other then the other, the other interesting thing is, can you, can you move workloads between these tiers once you've deployed things? So is the system or the platform flexible enough to let you change your mind and say, well, I didn't, I don't need as much performance as I originally thought, or I need more than I thought I was going to have. And can I transition between these things in a non-disruptive way? There's a lot of aspects to using storage as a service besides just the financial model. I'll tell you how I would think of it. I think it's a good comparison of that sort of on-demand thing

is to think about a warehouse, like Costco would be a good example, somewhere like that, where you as a customer are going in to buy stuff on a regular basis and you're only going to pick up one or two things at a time. But that warehouse has got to work out how it's going to buy from its suppliers and how it's going to stock itself.

And overstocking, they're never going to buy the next three years' worth of resources. They're not going to buy washing powder for the next three years and put it all in an enormous warehouse and hope that people buy it. They've got really clever strong controls around supply and demand about how much people are buying so they can order and they can stock much more accurately because they've got a much better control over their inventory now that to me flips into the whole thing we haven't talked about at all yet but you know the pure one side and all of your management tools you've been developing and that's that ability to be able to see what customers have been using on their platform help them understand the growth profile

and then you can be deploying the technology on demand into the into their environment as they need it so that you could meet that demand rather than putting three years on the floor so there's a combination here of some hardware techniques but there's also a lot of background software here that you've actually put together 100 I mean let me start here so yeah indeed right so we've built since the beginning all of the tools around our platform so that we can get usage information you know phoning it home and years ago we started building machine learning before people started really talking about AI there so that we can not only us predict what we think is going to happen,

but then also show that to our customers. In this case, you know, those administrators are now becoming product managers so that they can do their own, not just capacity planning around how many terabytes, petabytes they're going to need, but also performance planning. And part of that is simulation, what-if scenarios.

So what would happen if this workload was to grow by 2x? Or what would be the impact of upgrading this system to this new generation or that higher model? Or actually migrating those workloads from site A to site B? Do I have enough capacity to do that and then you know when actually when do i need to go and provision more capacity so we've exposed all of those tools uh through pure one um indeed our single pane of glass management interface that's a job that well i know previously i would have done and i would have done it with a lot of spreadsheets

and it would have been done with a lot of horse trading, for want of a better word, with the end users and trying to understand their requirements. And sometimes we'd run out, sometimes we'd end up, you know, panic deploying. I say panic deploying because a deployment could take four weeks to actually get on the floor, but, you know, it is still quite a panic when you know you've got a very rigid timeline. And I think for me that's, you know, is still quite a panic when you you know you've got a very um rigid timeline and i think for me that's you know that's a good example of probably a hidden set of attributes

that vendors like yourselves have put together which isn't necessarily always clear to everybody when they're when they're going through a buying process but actually is becoming more and more critical because you know if you haven't got the tools at the back end to support all of these things then you can't build a scale that people need things nowadays you just can't do it yeah there's also nuances that happen because of the way newer more modern products work like the the pure arrays so in traditional arrays uh like the example you gave earlier chris of front end back end that happens in aend that happens in a storage infrastructure, that also happens inside a storage array. You have the front-end that's serving front-end IO,

and then you have the back-end that's working to write data down to disk and maintain it. And in traditional storage arrays, there was generally a very easy to understand, like, one-to-one ratio between I do things on the outside and things happen on the inside. But now in modern arrays like the pure arrays, you have to manage the flash. You have to use the flash properly. And so there are backend systems that need to run and need to do work, not just to manage the flash, but also to help drive data reduction and compression and these kind of things and to continuously like turn the data and reduce capacity utilization, that sort of thing. So it

becomes much more difficult to do these kinds of like, what if and sizing exercises with a spreadsheet, because you need the system to help you answer the question of like, what if I put this kind of workload onto this array? What's going to happen to the load on that array? And we're not just doing a simple amount of front-end, back-end math. We're taking into account the way we've seen similar workloads behave on other arrays in Pure's fleet and all the phone home data we've collected and the AI learning and modeling we can do across similar workloads across different customers and then use that to help make a prediction as to what's going to happen. You simply can't just, you can't to do sizing and placement based on spreadsheets anymore, especially in really advanced storage systems

with data reduction and compression and backend services that also need resources to run. Yeah, that's a really good point. I mean, I hadn't really thought of it in those terms, but yeah, Fred, you're going to say. The way I think about it is these days, if you don't make fueled infrastructure solutions and all the tools around them to make that infrastructure

self-driving, how do you expect the administrators? Do you have the time to actually create additional value-added services on top of it? If all you do is managing the underlying problems and provisioning, then you just

won't have time to do anything like this. We've got to do all of that. And that's one of the reasons we've been building Fusion, is to enable that sort of work. Right. So I'm going to try and summarize some of the things we've just talked about there. And then I'm going to talk about what we expect as administrators, you vendors, to be delivering for us. Some of which we talked about and some of which I think we need to determine what should be like minimum requirements. But the one thing I

think that we've talked about in this discussion so far is that the job of the administrator, which is the whole premise of this discussion was to talk about the role of the storage administrator, that seems to be much more an advocate for the customer in terms of picking the right product, making it available, presenting the platform so it can be consumed, but at the same time, making sure that that's delivered and efficient and 100% uptime in terms of, you know, availability, and so on. So really, you sort of highlighted it as a term, Fred, I think, you know, they're more like a product manager for the customer rather than a hardware administrator or a system administrator. And that says to me that we've expected you as vendors to come and

give us a whole set of different constructs as part of our storage platform. And those divide into the hardware side and into the software side. And the consumption model side as well. And the consumption model side. Three things that the financial side, yeah, we should say the three aspects of that. So let's dive into the hardware and just really think about some of the things that have been developed in your platform over the years and try and give people a flavor of that as to exactly what has been built in there. Larry, you started off by talking about non-disruptive upgrades. Absolutely essential going forward. There's a whole lot more to it than that, isn't there? There's an awful lot more that's gone into the platform.

There's more than just non-instructor upgrades. There's also the tying together of the hardware and how the software works. So there's like a marriage between the software capabilities and the way it interacts with the hardware. So our hardware is custom engineered and custom built to work with our storage operating system. And that's like the primary way you're able to mix together the capabilities you built into the hardware platform

with the capabilities of the software that runs on top of it to really bring these kinds of outcomes. There's even more, isn't there? I mean, I spoke to Coz at an event last year which was in the uk and one of the things he was highlighting was the level of efficiency you're constantly trying to drive in in terms of reducing the rate overhead so you know you're constantly trying to reduce your costs increase the capacity of drives make those drives more efficient so you know you're you're having to drive the cost model a certain way from your perspective in order to be able to give that to the customer so the customer can continue to consume on a declining basis and that is a technology evolution

constantly that's right i mean the um well again right so capacity increases or requirement increase by 30 per year we have to beat this uh and at the same time we want to be able to address a lot more use cases i mean when when when we started, and you know that, Chris, we were addressing the really small top of the pyramid in terms of performance capacity. So really going after the most critical applications that need the most performance. These days, we're able to go and address

pretty much every storage in the data center, even things that a year or two ago were sitting on spinning disks. These days, we're able to do that on our flash array and flash plate systems. And part of that is all of the efficiency we've driven in the hardware and the software. Also the fact that we're building our own drives,

you know, dark flash technology. So today we've got 75 terabyte drives. We've announced that we'll have 150 terabyte drives before the end of 2025 and 300 terabyte drives before the end of 2026. So really just doubling and doubling again that sort of density. Part of the reason for this is to drive down costs, but also to drive down the power requirements to do all of this. Because again, a lot of the data centers are going to be full. Yeah, it's the density of the direct flash modules that drives a lot of the efficiencies in the platform.

And I would also say that we talked about hardware end-to-use in the past. And when you've been around hardware end-to-use for a long time, like at Pure, sometimes you can forget that it's not just about transitioning your platform across models. But we also non-disruptively consolidate and update the Flash media as well. So we have this, actually, honestly, I forget what the front-end marketing term for it is now. A friend might remember because he uses these words more than me, but shelf evac is what we call it internally. It was called capacity consolidation

from a customer-facing or marketing perspective. But that's the ability to get the old, less dense storage out of the system and replace it with new, more dense storage and to do that non-disruptively as well. So I remember back when I first joined Pure, I joined when the 400 series was already out there and we were telling SEs and customers to leave some room for NDU. And it was an internal sort of sales thing we had. And all the SEs were telling customers to leave one empty U of rack space because we were honest with our customers

and we told them this new chassis was coming and you'd be able to get to it non-disruptively and you'd need another U of rack space for that chassis to fit. And that worked really well. And a lot of customers were prepared for that. And then later when we developed the shelf evacuation thing, we had a similar thing where our shelves were going from, I think, 2U to 3U. And I tried to start a program called Leave Some Rack for Shelf Evac. But it didn't stick. No one liked the phrase. But we did do it anyway.

We just didn't call it. We didn't give the program a cool name. But yeah, the non-disruptive upgradability of the hardware spans all the way from changing the storage platform whole out or changing the kinds of media you're using. And if you think about it in terms of density, it's ridiculous. Like 11 years ago, the largest drive we were selling was 256 gigabytes these days it's 75 terabytes and we've increased the number of drives you can have you know in a given chassis so like we're talking petabytes of wall flash in in a three-use system well yeah when i joined it was just 10 years ago and i updated this spreadsheet i maintained a

spreadsheet that fred would have to use to understand how much capacity customers are going to get and it was like 12 12 and a half terabyte systems 22 terabyte systems and uh we had t-shirts made when we got to 70 terabytes of pure flash we had t-shirts that said that so yeah just in the one decade i think many orders of magnitude wasn't the first product was five and a half terabytes yeah then I think very we had we had sales of five and a half terabyte indeed with which was basically 22 drives of 256 and then we had 20 runs yeah yeah to show you how things have changed okay so when we look across what we've talked about,

you know, as an, what do I call it? Do I call myself a retired storage administrator or something like that? I don't think the best way to describe it. But, you know, I look at it now and think my world would have changed significantly. I'd have had a very different set of requirements for my end users.

I'd have had a very different set of tasks to do. My business focus would have been a lot more different to the way it was previously. And I'd be coming to vendors like yourselves looking at a split between efficient hardware and software that would allow me to manage this estate of technology much more efficiently, as well as having some financial models

that allow me to consume it better. So we know about the hardware. I don't know whether we actually, funny enough actually, Larry, I don't know whether we touched on specifically the naming of the software and the SaaS platform that you have there. Is it worth just you spending 30 seconds just to remind people what that is? Yeah sure, Fusion is a SaaS-based software that helps you manage massive fleets of pure storage systems with a cloud operating model. Looking at that then, you know, you've got the hardware, you've got the software and

things like Fusion, you've got the consumption models, which we already touched on. It's a very different world, isn't it, Fred? You know, I think we've highlighted that you've evolved your products very much to fit the requirements of the modern storage admin job. And really, the admin has evolved as well as the technology has evolved. In fact, they both sort of evolved together. And really, they address, I think, what people really want in their modern environments. That's right.

And I think one of the operative words that Larry used here is cloud operating model. We think that cloud is not a place, but a way of doing things with different aspects, self-service, abstraction, and indeed something that ties into the end customer's requirement. So that's what we're building. That's what we've been building for years, not just the platforms to underpin these,

but the software and the business models to enable that cloud operating model for our customers and their customers. Okay, brilliant. Well, I think it's been a really interesting discussion. I think it's highlighted how things have changed. And I think we've gone off in lots of different directions. And sometimes when you listen to what we talk about, you might have to go back and listen to this again because it was quite a long discussion.

But I think we've just touched on some very interesting things i'm very much looking forward about what's coming up at accelerate and i'm sure there's going to be lots of interesting stuff there that's actually not that far away now isn't it it's only i think two months away yep it's happening in june um i want to say june 19th but it's a multi-day event that's the uh it's that sort of time frame isn? It's around that sort of time. There will be a London version on September 24. Okay, so we'll make sure we put those details in the show notes. We'll spend a bit of time in the notes as well, just summarizing some of the things we've talked about in this discussion

for people to go and look at. And I think I'd like to point people at some of the hardware aspects, the software aspects and the business models. And we've got some previous podcasts and another content we can just push back, push people back to look at from before. For now, though, I think, you know, great conversation, guys. It's been great to actually have this chat and definitely look forward to being able to catch up and talk about it again in the future.

So do we. Thank you very much, Chris. It's been great. Yep. Yep. Thanks for having us, Chris. It's been great. Yep, yep. Thanks for having us, Chris. It's been a great chat. Cheers, guys. You've been listening to Storage Unpacked.

For show notes and more, subscribe at storageunpacked.com. Follow us on Twitter at Storage Unpacked or join our LinkedIn group by searching for Storage Unpacked Podcast. You can find us on all good podcatchers, including Apple Podcasts, Google Podcasts, and Spotify. Thanks for listening.