Hybrid Storage with Pure Storage

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to a special sponsored podcast from our friends at Pure Storage. It's going on a couple of months now. We did a webinar with them talking about cloud-native storage and helping developers use and consume cloud-native storage. We're going to extend that conversation into the hybrid infrastructure. Today I have with me Dan Kogan, VP of Product Management, and then Cody Holtzman, Director of Product Management. Guys, welcome to the podcast. Thanks for having us, Keith. Yeah, thanks.

So we're going to start out the conversation real simple. Pure Storage is a mission-critical SAP, HANA, SAP, go as fast as you can, traditional system-of-record storage array provider. How are you guys even relevant to the cloud-native conversation, Kubernetes, et cetera? I've run into Pure Storage throughout my past few years in this more traditional data center role. Yeah, so I think there's a couple pieces here. I think there's a few places also framing the conversation. There's the public cloud. There's just Kubernetes in general.

And let's start with Kubernetes in general. One of the shifts that we've seen with anything with infrastructure is there's an early adoption. And then once that adoption goes through, we get to that critical mass where critical databases and applications start coming in, things with persistent data. And persistent data needs to be protected. It needs to be performant. And they have generally fairly sophisticated life cycles. And that's something that we've always focused on at Pure, from bare metal databases to virtualized and now containerized.

And so that shift is now just kind of falling into this is the needs of the application fall under FlashArray. And from a cloud perspective, it's a similar thing. Customers are looking to continue to look to adopt public cloud with their on-premises infrastructure, and that generally means hybrid cloud. And when it comes to implementing those types of configurations, they need those critical databases and mission-critical databases in both places. And they want to use them both effectively. And we play in both those arenas.

And that's where we initially come into these conversations as customers are deploying those models. Yeah, I think what we first saw, so we did the work a few years ago to take our Purity operating system, which runs on FlashArray hardware, and natively build that on top of the infrastructure provided by AWS and Azure. It's a product we call Cloud Block Store. But same experience, same APIs, same data services that you get on-premises. And I think what we saw with that first were really kind of extension sort of hybrid use cases where customers use the cloud side for DR, for DevTest, but still running the production predominantly on their FlashArrays and their data centers.

As more customers have moved out of the data center business, if you will, and have moved applications and workloads into the public cloud in an IaaS model and still running traditional OLTP applications, those kind of things that run on block storage and do really well on Pure, they start to see massive, massive sticker shock. A lot of the data services we have that I think people take for granted, data reduction, thin provisioning, space-efficient snapshots, those kind of things don't really exist in the cloud.

And customers, for whatever reason, don't learn that until after they've moved over and start to see the massive storage costs. So that's another kind of segment of customers we're seeing coming our way are those who don't want to completely change their architecture, rebuild their applications, they just want to run efficiently and do it not within their own data centers. And so we're starting to see a pretty big hockey stick around those kind of use cases. So as we're seeing this hockey stick, one of the things that I get pushed back all the time when we're looking at these arrays and services that have run in traditional data centers is that they don't really fit the mold of cloud-native and public cloud data services, or even not so much data services, because I think data services are data services.

They don't fit the mold of application development of the cloud and public cloud, that there should be brand-new constructs built from the ground up that serve these needs. How would you counter that point? Well, I don't think I would necessarily counter that point. I think it's a valid one in the sense that customers are looking to move to that cloud operating model, and it's not just public cloud. It's also on-premises. On-premises, customers are looking to innovate with hardware but not really necessarily be concerned about it.

And they certainly don't want to be concerned about a specific array. They want a volume. They want data services with that volume, wherever that happens to be. And from a pure perspective, we agree. There needs to be a change in an operating model, whether you're on-premises or you're in the public cloud. And this is where our product Pure Fusion comes in. Our infrastructure as code, or really more storage as code platform, that removes that focus on some array or two arrays, really to around API provision storage to the applications that need it where it happens to be, whether it is a fleet of arrays on-premises or a fleet of deployments of cloud block stores.

This is really the focus is to shift that model. Yeah, or both in either way. Fusion kind of creates that unified management plane that allows you to operate in the same model and kind of build your storage availability zones wherever you want them to be. Whether that's in your data centers, whether that's in AWS or Azure data center, it's still that unifying bridge that very much takes the physical arrays, abstracts them, and the end users operate at a volume as a service level, similar to how they do with an EBS or an Azure disk and those kind of products.

And from the back end, from the storage teams, it's very much they're living in a policy-based world where they're creating the infrastructure that's available on demand, the policies by which that can be consumed and almost play more of an SRE role with a lot of automation behind that. So help close this loop for me because one of the things that I'm struggling to picture is as a storage engineer, I'm consuming a policy that may exist between my traditional on-premises workload. Let's say SAP is submission critical app.

It is highly performant, so I need to put a storage policy behind that. I'm also building similar apps that will be developed or consumed, data that will be developed or consumed against in the public cloud or the hybrid cloud, you know, private Kubernetes deployment. Those things from a application interface perspective, I mean, how I consume them don't look the same. Like SAP is kind of invisible. You know, I present a set of lungs to a store, to OS, and that those lungs have a – I'm just giving an example.

There's different ways to do this. But as, for example, those lungs have a policy behind them that's created. But then if I'm doing it from, let's say, Kubernetes, I'm consuming a persistent value that is more of a namespace. How – I'm not getting the bridge in between these two worlds. How does Fusion make that manageable for my SRE-type storage engineer? So I'd say there's a couple pieces here, right, is that when we look at Fusion, we really look at two types of – two groups of people.

There's the providers and the consumers, right? And what the consumer is changes, right, whether it's a VMware administrator, whether it's an application owner, whether it's a Kubernetes administrator, whether it's a SAP administrator. They have different needs, but what they do need is they need resilient and high-performance storage, and they want it to be provided to their application. But how they consume it can differ, right? So if you look at Kubernetes, the persistent volumes, as you referred to, come from a storage class.

And really, what does a storage class map to? It maps to a storage policy, right? And so that concept there comes together quite well. If you look at more traditional applications like SAP, like SQL, where do they want to provision their storage from? Well, often, like, you know, you use SQL Server Management Studio or those native apps. So having the API to present that to the layers where the administrators actually manage their storage, whether they're making changes every day like Kubernetes or not when it comes to something like SAP, having that integration layer is important, but making sure it's up the stack further and in the tools that the administrator uses every day is super important.

And that's always been a driving focus for us when it comes to solution and integration work. And I think what Fusion does is it makes that overall plane much simpler for the consumer and also makes it much easier to manage for the provider that might have hundreds of arrays to deal with on the back end. So if I'm hearing you correctly, let's continue to pick on Kubernetes. Yeah, yeah. Fusion becomes that provider to the CSI. And I'm creating my policy as an engineer.

I'm creating my policy within Fusion. And I have as much depth as I would like. If I want to know, you know, where replica sets are going, et cetera, et cetera, that's Fusion. That's my view. But if I'm a developer or platform team, this is just my gold level that's labeled gold Fusion storage within my name, my Kubernetes CSI namespace type setup. Yeah, exactly. I think one of the historical problems with policy-driven storage is that policies were used to try to extract away complexity.

But often they ended up just passing a lot of that complexity up the stack. Like a policy based on RAID is kind of a weird thing today, right? So it's a big part around the simplicity of Pure. And then Fusion is that they're not abstracting away that complexity of, like, what I need to do to configure my storage. They're just making it easier for that consumer to consume it, right? It's not necessarily about, like, is the storage less complex because we put something in front of it?

No, it's always simple, and that's what we've been doing from day one. But making sure it's simple to consume from an API layer, mapping storage classes to something that's actually real on the back end, not some initial abstraction around complexity is really, really important from that. And so that's exactly what we would see from a Kubernetes perspective, that these storage classes are based on high-level SLAs, right, or potentially availability zones, depending on where they're trying to provision from and how they're trying to protect their application.

So help me, if I'm a platform team owner or manager and I'm looking at getting this hybrid type of solution and I've looked at the market and I'm looking at Pure Fusion and I'm thinking this is what I want to get, but I'm a customer of some other big iron storage provider, how do I start out with Fusion without buying a big iron Fusion storage array? Well, I think an important part here is that Fusion is not just about FlashArray on-premises, and to Dan's point, it's also about Cloud Block Store and the public cloud, right?

CBS is at our 100% software solution, and it's not just a virtualized version of FlashArray. It is an architected platform to make the best use of clouds, AWS and Azure. We do just like we built FlashArray for Flash to understand how all that works. We built Cloud Block Store to understand the storage resources in the cloud. So, no, you don't need a data center with a FlashArray to be able to go this route. You can start wherever you need to start, and it can be simple just to deploy a CBS, right?

And that's a reasonable place to start if you don't want to go the whole initial buying FlashArray. Yeah, it's a tough set up a little bit in that Cody's right. The cloud is the way you can get into with our cloud product without physically procuring FlashArrays or do it through what used to be Pure as a Service, now known as Evergreen One. And again, you're more capacity-based at that point. But, you know, there's a lot of native capabilities within the FlashArray, the purity software that enables Fusion to do what it does.

Like we leverage the active cluster work and to be able to do transparent workload mobility. We leverage the metadata in Pure One from an AI standpoint to place workloads. And so kind of that core experience relies on the software that sits within the FlashArray product line. I think it would be including Cloud Block Store. It would be phenomenal, I think, for all of our customers, for everyone, if Fusion was able to be this master control plane for all of your storage infrastructure.

It doesn't matter which vendor it's from and be able to take it over. But at this point, there's just so much built into the FlashArray operating system itself to be able to let Fusion do what it does so well that, you know, we have to kind of have that conversation with our customers. Do you want that immediacy? Do you want to build out this true storage-as-code, DevOps-style infrastructure and operational standpoint? If so, it's going to work on the Pure estate really well.

Or, you know, do you choose to do nothing and try to find something that's completely heterogeneous? So I love the honesty and I love their approach. So the question is, ultimately, how do I provision this low-level storage in a cloud provider perspective? In this case, I want to get to the Fusion OS so that I can consume Fusion as this abstraction layer. And right now the focus is, again, on providing pure storage via Fusion to my hybrid infrastructure. What is the buying experience of buying the storage solution itself within the cloud providers?

Is that something that I find in the marketplace? Do I need an expert in pure storage to deploy it? Like, what is this experience? So there's a couple options, right? And I think flexibility is a key piece here, especially when we've seen customers deploying and growing data centers on-prem. They have a cloud move, a cloud shift. They're like, how do I buy both? How do I simplify that process? And Dan referred to a program we have called Evergreen One.

We used to refer to this as Pure as a Service. You can see some older posts around that. And a really important part around how it's licensed and purchased is the fact that that Evergreen One license is applicable for FlashArray and Cloud Block Store. And it's not tied to an array or a model. It's tied to your data, right? So if you do move data from FlashArray and then move it into CBS, that license follows with it. And so when it comes to planning on where it's going to go, how that application is going to be deployed today or tomorrow, that flexibility is particularly important.

Because we'll see customers that are like, hey, we're looking to extend our on-prem footprint or, you know, refresh our on-prem gear. But we know we're going to move some of those applications to the public cloud in the next year or two years. And so we don't want to buy something we may or may not need. But we don't know what cloud. We don't know what applications. We just know we have a mandate to look at these applications and make some shifts.

And that's where the flexibility of Evergreen One really comes into play with both of those products. Yeah, we had a customer say it really well at a recent conference from Delta. It talked about not having their data held hostage or the capacity held hostage on an array. So over, you know, you buy a large array, maybe your needs change. Maybe you start to operate more in a hybrid model, but you're locked into that thing you've purchased. So that's really what we want to avoid, our customers having to be in those kind of situations.

And that's where the Evergreen One pricing model and the new Evergreen Flex model both play into that. And so if a customer backed Evergreen One, the customer is subscribing to capacity, and that's backed by performance classes. We provide, if it's on-premises, we're providing the arrays to map to and deliver against those SLAs the customer is subscribed to. Or they just run it in the cloud, which is how they get into that from Fusion, from a cloud standpoint. Or sorry, get into our cloud product from a cloud standpoint.

We do also sell through the marketplaces, and a lot of our customers prefer to transact that way. So they can still draw down on their large, you know, Azure agreements or Mac agreements with Microsoft or their big enterprise agreements with AWS. So VMware, or I'd rather say VMware Explorer, we still got to get used to calling it Explorer in just a few weeks around the corner. You folks are big sponsors of that show, coming in with a platinum booth. So you got to have a platinum-level story around this uncertainty that VMware customers are experiencing.

How is pure storage helping customers of VMware, no matter what happens in the transition and transaction? How are you helping customers have consistency in their operating model, especially around data? Yeah, so there's a couple pieces to this, right? I think one is we're starting to look at customers are really starting to dig into the dual application architecture deployments, meaning that I'm going to have some VMs, and I'm also going to have some containers. What do I do about it? And in reality, this is not a new story, right?

This shift was 15 years ago from bare metal to virtual machines, and bare metal still exists. I mean, look at Project Monterey, right? Project Monterey is about using ESX, right, essentially like running it via SmartNIC and so forth to manage bare metal that might be Windows, might be Linux, and you might also have hypervisors. So that part of the story is not going away, and now we're adding containers to it. And so how do I manage three potentially different infrastructures? And certainly VMware is investing in that.

Their Tanzu platform, Project Monterey to go kind of both ways. And an important part around that is also from an on-premises perspective, that innovation with hardware. But our focus, our VMware strategy overall, is to enable these organizations to, one, be able to simply manage all these things together. So our focus has always, always, always been simplicity, not tying it to a specific offering, right? So, for instance, Portworx, which is an important part of our overall Kubernetes strategy, is not specifically integrated to this version of Kubernetes or Tanzu or OpenShift or EKS or AKS.

It's focused on Kubernetes. One of the primary early use cases for Portworx was moving to a new version or release or model of Kubernetes, making that flexibility really, really simple to make that shift. And from a FlashArray perspective, from a core block perspective, our focus from storage up has been around what you're talking to, building storage policies, providing ransomware protections in our features that we can deliver up into those storage classes within Kubernetes as well. And so whether you're using, you're going the VMware route with Tanzu or you decide to go another way or you want to make that shift, we're building these feature sets to be relevant regardless of where you want to go.

And so I think really that flexibility has been our focus and that ease of moving applications but keeping that consistent model wherever you go. So I hear you if I'm thinking about moving from, let's say, Tanzu application platform tap or TAS to OpenShift. That's an on-premises move. Fairly straight forward, Kubernetes is Kubernetes. But what if I want to go to the public cloud? Let's say that I'm transitioning both my VM landscape and my container architected applications into the public cloud.

How do you help with that assurance? That's a great question, Keith, because it's actually been one of our early driving use cases around Cloud Block Store was that exact situation. It's that, hey, I have on-premises VMware VMs and I want to move them and I want to move them directly to native AWS EC2 or I want to move them directly to Azure VMs. But I want to keep the data policies, the scripting, the usage, the features, the efficiency that I have with on-premises FlashArray.

And this is one of the many reasons we've significantly invested in vSphere virtual volumes is not only for the benefits from a VMware perspective, but also the openness of the data format. We can replicate those vBalls directly into CBS and present that SQL database or whatever it is right to that EC2 instance. And so that open data format that we offer for VMware environments makes it really easy to move it to public cloud or to move it, move that data set, that database to some other on-premises hypervisor or bare metal.

So that's been a really important part of that strategy and why we've also invested in it, not just because it's a really great storage solution for VMware and there's a lot of cool innovation going on in that space, but also for the data format, we can easily move those large databases that these customers are concerned about and keep that interaction, right? Being able to SQL Server management, SUDI integrations, all that type of stuff around the data protection and management, they can move the data set and not lose all that stuff.

And that's that's been a key part of that overall VMware strategy for us. So I'll give you to the last word. We've talked about quite a bit. I've given you quite the hard time. Anything that we missed you want to make sure you highlight going into VMware Explorer? I mean, I would say there's one of we alluded to this briefly, but I do want to mention it. You know, one of our overall company focuses, which is which is not a unique concern across our customer base is ransomware.

The immutable protection that we offer on FlashArray and Cloud Block Store, these things are super relevant. And it's not just about providing protection and assuring it's there, but also being able to restore, but critically restore really fast. Right, because if you restore takes days or weeks, then you might as well pay the ransom. Right. Depending on the impact your business. And so our focus is on all parts of that protection. And that quick restore is something that we can really, really effectively do on FlashArray and Cloud Block Store in both places.

And so that's an important part of the strategy, whether you're going Kubernetes, you're going to AWS, you're using VMware, whether you're using bare metal like that. That feature there is a critical part and something I don't want to forget to mention. Yeah, everything we do continues kind of that path of speed, efficiency, automation, ease of use, and more and more focus increasingly on the data security side of the house. And again, those same principles of speed, efficiency and ease of use getting built into the into the rapid recovery and data protection piece of the equation.

Yeah, this is a great conversation for a future show or podcast. We've just invested a great deal of time in looking at ransomware for our hybrid infrastructure and thinking through how do we protect or we specifically recover from ransomware. Something that keeps me up or kept me up at night so we can definitely talk about doing it at the storage level versus doing it at the backup and DR perspective and the advantages and disadvantages of each. com or visit them at their VMware Explorer booth.

I'm sure we'll be right around the corner of them and you can stop by and talk to me about this or any other topic. You will learn more about the CTO Advisor in general and you won't be at VMware Explorer. com is the website. Next CTO Advisor is my Twitter handle. If I didn't go hard enough at these two guys in this sponsored podcast, bring the heat and the questions to my Twitter feed. I'm always looking to engage and talk to you.

Next CTO Advisor, CTO Dose.