Grey Beards on Systems - GreyBeards talk all-flash storage with Vaughn Stewart, Chief Technical Evangelist Pure Storage

Episode Date: September 16, 2014

Welcome to our 12th monthly episode where we return to discussing all-flash storage arrays, this time with Vaughn Stewart, Chief Technical Evangelist for Pure Storage. This our third all-flash storage array vendor that the GreyBeards have talked with since the start of the podcast, not counting server side flash and scale-out/hybrid storage systems. Vaughn has had a long … Continue reading "GreyBeards talk all-flash storage with Vaughn Stewart, Chief Technical Evangelist Pure Storage"

Hey everybody, Ray Lucchese here and Howard Marks here. Welcome to the next episode of Greybeards on Storage monthly podcast, a show where we get Greybeards storage and system bloggers to talk with storage and system vendors to discuss upcoming products, technologies, and trends affecting the data center today. Welcome to the 12th episode of Greybeards on Storage, which was recorded on September 5, 2014. We have with us here today Vaughn Stewart, Chief Technical Evangelist of Pure Storage. Why don't you tell us a little bit about yourself and your company, Vaughn? Hey, guys. Thanks for having me on the show.

First off, what do you mean September 5th? It's September 6th where I'm at. All right. All right. You're in the future. You're in Australia. We're in the U.S. I guess we'll have to deal with that somehow.

Hey, look, it's great to be on the show. You know, I know we all just caught up with one another just a few weeks back at VMworld, and I appreciate the opportunity to come in and share with you a little bit about what we're doing at Pure Storage. I guess, what would you like to know? Well, you can start with what is it? I mean, obviously it's a storage device of some type. Sure. So Pure Storage was founded on the vision of enabling flash storage to be broadly adopted throughout data centers. Currently, we ship a product. It's the FlashArray 400 series. This is comprised of entry-level, mid-tier, and a high-level storage array, and they scale it both in performance and capacity as you go through those tiers.

The systems offer block-based storage access, so iSCSI or fiber channel, with the bulk of our sales being fiber channel. No kidding. That's good. So SCSI or Fiber Channel, with the bulk of our sales being Fiber Channel. No kidding. That's good. Yeah. And the design of the systems is 100% Flash. And through a product, what we call, or a feature set we call Flash Reduce, we provide five forms of data reduction technologies that allow us to invert the price premium of flash storage and offer it at a price point on par with that of spinning disk, high-performance spinning disk, I should say. And thus, our target market is really tier one workloads, be it OLTP databases, virtual infrastructures,

and virtual desktops being the three primary areas of focus. So it's an all-flash array? Correct. And is it – so you mentioned five forms of data reduction. Could you expand upon that or expound upon that? It sounds kind of like build strong bodies 12 ways. Sounds a little marketing-y to me. All right.

Well, you know, we still want to know what the hell it is. Well, look, you know, storage systems have had forms of data reduction built into them for quite some time. And they've slowly trickled from the backup space, you know, a la data domain. But even prior to that, right, we were compressing data as we were putting it on a tape. So we spun from tape backups to disk backups. I was the one who brought NetApp's block-level deduplication out from the backup use into the production use with server virtualization back in, what was that, 07, 06, 07? Yeah, yeah, yeah.

You know, so we learned a lot from that, and that's actually part of what drew some of my interest a few years back with Pure Storage. Different types of data, or different types of data sets to be more specifically, have different responses in terms of the benefits or gains based on the type of data reduction technology that you apply towards them so pure storage groups our collection of data reduction technologies and we refer to them as flash reduce and so basically we have an inline form of pattern removal pattern removal is the process that some applications or systems or i should say patterns is how some applications or

systems try to subvert thin provisioning mechanisms. So we have pattern removal, so to keep all data on the system thin. Second, we have an inline form of data deduplication. It's very granular. It has a 512-byte granularity, which allows us to provide the greatest benefits or returns on capacity across a data set. And the 512-byte granularity we can get into a little bit more if you'd like, but granularity block size really demonstrates its strength over the long haul as data blocks start to get dirty and guest file systems of the objects that are being stored by the array.

We also have a form of inline compression. And so compression and deduplication kind of at a high level service to two different markets. Deduplication sees strong data reduction returns on unstructured data sets or where you've got file commonalities such as the binaries within virtual machines, whereas the strong suit for compression is really within the application space. So it's three forms. The fourth form is what we call deep reduction, which that is a marketing term.

And deep reduction really is a second form of compression, one that's much more aggressive than what we do inline. And we pair that with the back-end system process and garbage collection so that as we are having to manage the data over its long period of time, we're actually returning additional capacity savings to the array. And that deproduction provides another 2x capacity reduction over the original compression on the inline element. So is that application-aware filters like Ocarina used to do, or is that bigger dictionaries in the compression algorithm,

or is that just magic? Well, yeah. Step A, step B, and in between, this is where the magic happens. So the inline compression is, it's best to look at it this way. So compression has a correlation between the amount of CPU that you can throw at the algorithm and the data reduction rates. And so what you see across the industry on inline compression is a very moderate form, usually one of the LZs. It could be LZ4 or, you know, we're LZO. And our LZO is, if you think about it in terms of aggressiveness, let's say it's set at about one-third aggressiveness

in terms of its max. And this gives you the ideal mix between data savings on ingest as well as still being able to maintain some millisecond response times externally. When we transition to deep reduction, what we're actually doing there is at the time of garbage collection

where we're having to move valid data cells because we want to erase a block that has some invalid data cells. When we go to move that data, we actually apply a more aggressive ratio of the LZ0. So say going from one-third aggressiveness to about two-thirds of max settings. And then we also apply a very aggressive proprietary form of Huffman encoding. And the benefit of this approach is obviously to net customers more capacity on the system during a normal operation that every flash device has to do, right? Every SSD has to garbage collect. But by being able to layer these two and do them post-process,

which is funny because some vendors knock this, but to actually do it post-process is to be able to provide a form of data reduction that's just really too taxing to do in line. And so I don't understand some of the FUD that throws around. But, you know, we've all been around the storage block. It's kind of just the state of the union. Sometimes you just find something that's different.

Yeah. Different or, you know, storage vendors are like that you wouldn't do in Candide's best of all possible worlds, where 156 core processors cost $10. It's funny because it's, you know, alien technology across vendors is almost like,

you know, it brings out the xenophobe and everyone must crush it. But the reality is that system architectures are designed with trade-offs, right? And so you design your system for a type of workload or a type of functionality. And, you know, while many of us think Intel processors are these magical beings that can do everything, and they can, they just can't do everything simultaneously. Right. Yeah. So you got up to four. What's the fifth and final deep reduction technique?

Yes, as we roll the tangent back in. We don't always do that. Yeah, you're right. We consider that a success. Yeah, okay, thanks. And we digress again. So the fifth is to actually not write the data at all. So as you know, these data reduction technologies come together to reduce the cost of the system, but

probably what many people don't realize is the data reduction technologies actually increase the resiliency of the flash media because the flash media itself has a limited life cycle. Every byte you don't write is one write erase cycle that FlashCell doesn't have to go through. Exactly. So you mentioned, so the fifth is actually like a copy on reference snapshot kind of capability? Is that what you're saying? Yeah, think of it as, I'll put this in generic storage terms,

think of it as a pointer-based copy. I've got a set of data blocks on my persistent layer, and someone wants to make a copy of it. Instead of writing the data a second time and or then having to deduplicate the data a second time, why don't I just make another metadata reference pointer to the data and now have two instances of that object versus one? Yeah, so if a write comes down for one of those instances, then you create an old version of the block or something like that? Is that how it plays out? So the two predominant use cases we see are in virtual machine cloning via hypervisor or database clones. And so when I'm receiving a request, let's say from VMware, leveraging their XCopy API set, it's saying take this block range that I understand to be a template of a virtual machine and make a second copy of it. And we respond back with saying, okay, well, here's a new set of external logical block

addresses that make up your second reference, but they're just metadata reference pointers internally. You know, the provisioning, the metadata reference, cloning an entity on a storage device by additional metadata reference pointers is really the inverse of taking two identical sets of data and collapsing them onto each other through deduplication. It's two sides of the same coin. I've reached the point where I think that, you know, what I've actually started calling, you know, what you guys are doing, VAEI unload.

You know, we're not offloading it. We're offloading the work. We're having the array avoid the work altogether and put in metadata pointers. As far as I'm concerned, that's table stakes for a modern storage system. Yeah, anymore. I think I would actually take that a step further and say, and I actually just wrote a blog post on this that I think is going over to InfoWorld. I don't know if I can say it.

If I can't say that, bleep that out. No, go ahead. It's okay. I think storing your data in space-efficient constructs is the new norm. Yeah. And there's a lot of nuances between how those technologies work and operate. But if you look at the data growth rates that are occurring, I don't know how we're going to reverse the trends any other way outside of storing data, leveraging the CPU cycles to store the data in a more dense format.

Yeah. Well, and the greater overall efficiency of the system, especially when we start dealing with constructs like VVOLs. If you don't have metadata that can handle dealing with things at that granular level, boy, is that implementation going to stink. Oh, and so don't even get me started on the VVOLs. I mean, we've been waiting roughly three or four years. And I think as an industry, we are really hoping for this payload to deliver

on its promises. But if you look at something as simple as the copy offload that's available today with the clustered file system in VMFS, there's still an intermediary there in VMFS. It's gating the transfer rate of the IO. And when we actually move to vVols, there is no more gating. It's gating the transfer rate of the I.O., and when we actually move to vVols, there is no more gating. It's a direct handoff between a hypervisor request and a storage controller's response. So you'll actually get even greater performance with vVols. Take that then a step further, and we'll actually get to see T10 unmap at the guest layer, right, in terms of the actual virtual machines operating system, you know, wow, you know, to finally be able to free ourselves of the garbage that's accumulating inside of file systems of virtual machines on data that's no longer required. Now, there's still some tap dancing that's required throughout the ecosystem to make

sure that data is not sitting in operating system constructs like, you know, temp spaces, either system or user or recycle bins, but you can handle that through different policies, etc. That's interesting. That's interesting. I was going to say, one of the ways we're going to deal with this data growth capacity issue

is that Seagate just came out with 8TB disk drives. Were you guys at Flash Memory Summit? One of the vendors announced 14TB SSDs that fit in a 2.5-inch at Flash Memory Summit? One of the vendors announced 14 terabyte SSDs that fit in a 2.5 inch form factor. What? For 2016. 18 to 24

months out. I mean, today you're seeing a handful of vendors really push the tier one storage market to say Flash is available at a price point of Tier 1 disk. And this is HP, EMC, Pure Storage is an example. These are the folks that are leading this change.

When you get a 14-terabyte drive and a 2.5-inch drive form factor, that means the Tier 2 market's next. It's two years out. Oh, come on. Now you're not going to go after Tier 2. I think Tier 2 is going to happen. There's different scales in terms of system, access protocols, etc. But I think Tier 2 comes quicker than most people

are expecting. Huh. You know, I was at a dinner at... If the disk drive vendors miss their targets on bit pattern media, if Moore's Law holds and crider's law doesn't and and there is the opportunity because there's that big technology shift that we haven't seen them try yet um i could see that happening you know clearly you know in my old home of new york

that'll happen pretty quickly because the floor space costs are going to be an issue. Because we've already reached the point where a two terabyte, two and a half inch flash drive is denser per cubic inch than that eight terabyte Seagate three and a half inch drive. Yeah. Yeah. It's funny. So we have conversations with some very large customers. And when you get into areas where there's just dense population, so it could be the financial area of New York, it could be London, you can be sitting here where I'm at in Sydney, Rackspace or data center resources more specifically, the power, the cooling, the rack space, they're at a premium. And in many of these locations, it costs more to just power a storage array annually than it does to acquire a storage array. And Flash is the way that you invert that trend. It allows you to take whatever the data capacity is of a data center today and extend it tenfold or twentyfold into the future. I don't believe it. Look, I didn't say tape was dead.

Thank God. Jesus. What's with tape? I never talk about tape. Everybody else talks about tape. I never talk about tape. God damn. I'm sorry. Getting back to the world here. So, all right, so Pure Storage is data reduction with all flash and all that stuff. I don't think I've seen any SPC1 benchmarks with Pure. Is there something here I'm missing? Well, there's much more to the system architecture outside of the efficiencies,

but that is the disruptive economics element. Without it, we don't have a conversation. We're sitting in the camp of tier zero. We are kind of at an interesting point with the SPC benchmarks because, to the best of my knowledge,

they don't accept any results where data reduction technologies are a part of the system. The question then becomes, should we not participate in SPC benchmark and invest our resources in other areas, or should we complete an SPC benchmark and know that it can't be certified? Well, yeah, my opinion, I mean, you could go in with an SBC benchmark and, in my mind, I guess, can you turn off your reduction capabilities? You can't adjust any of it.

That's the beauty of an all-flash system. There's no knob tuning. You can't adjust it. You can't turn it off. No. Yeah. So if you could turn it off, you could go in there. It would be a much higher price and you could effectively put words around the fact that with a

5x data reduction capability, it's going to be much cheaper. But if you can't turn them off... Then you'd be generating test data that doesn't reflect the real world. This is how fast it is with this feature turned off, but nobody ever turns it off. Yeah, and you bring up a really good point when it comes to benchmarking or testing these systems. I mean, IDC has published a report that gets referenced quite extensively within the market around testing an all-flash array. It's got some great information and guidance within the report,

but it also has some what I'll call antiquated views on how to test the systems. And we and other vendors have been reaching out to IDC, and to their credit, they've taken this feedback and are working on an update to their all-flash-ray testing methodology document. The way I look at the world is a third of the customers you meet will swear by testing with synthetic workloads. Another third will swear by only testing with real data. And there's this remaining third that's kind of undecided. But what we see spawn from this IDC test report is this big surge on synthetic workload testing and particularly characteristics that aren't seen in the real world. And again, it's very interesting because, as I said, there's this engineering centricity

within our profession that some people think that data, while having an extremely low probability, is highly relevant to their decision process. And others view it the opposite way. What about Exchange Solution Reviewed Program, ESRP? You could submit a solution there. There's not a lot of flash solutions in ESRP results. I was attributed that to maybe some characteristics of OLTP workloads and disk solutions. Yeah, we've seen some pretty significant data reduction results with some customers who've put Exchange onto Pure. I don't know where we stand within the Alliance team. I know we're doing a ton of investments within Microsoft

spanning from integration points, such as we just released a VSS provider within Purity Operating Environment 4.0, but also going up the stack into points of integration, certification within the platforms. So I don't know where we're at with the Exchange benchmarking, but I can follow up with you on that offline. Your deduplication model should work quite well for Exchange.

Exchange is a difficult data set to reduce because it's constantly defragging the database. And if you use a fixed chunk size, things get very strange. Yeah, so you're right. So as well as the attachments, or I should say the Microsoft Office files, in the modern versions, all those files are actually compressed formats. Right. So variable block size, which I know I said 512 byte granularity, but the variable block size that is enabled by having 512 byte granularity,

as well as multiple forms of compression, allows to reduce those files, office files, rather well. But then if you also look at how Exchange stores data, which is there is no form of single instance anymore. And in fact, significant redundancy around availability groups. We can collapse those environments quite aggressively.

What I think more of an interesting construct when you actually go beyond the technology is when you say I have an all-flash array, you tend to elicit a response from 80% of the market, which is, ooh, flash. That's only for some mission-critical workload.

I don't know if I need that within my data set. And yet there's this smaller subset of the market, and it's a growing subset that is starting to recognize, if I can take the economics out, which, again, I think is the play that you see occurring with HP, EMC, Pure, etc. If I can take the economics out and I've got to spend my budget on storage regardless if it's disk or flash, flash with sub-millisecond latency actually makes the use or the quality of the experience with every application better. And so what we see with customers who have moved Exchange onto Pure is this

Google-like interface experience when you're in your Outlook client. I start to search and I'm getting immediate responses back. My troving of my archives is no longer a waiting task that you avoid. It's an immediate response, much like what we receive. How many cores do you have on your desktop? Yeah. Not enough. Because doing searches in Outlook against the SSD in my desktop isn't a Google-like experience.

That's because of that cheap SSD you've got in your desktop, Howard. So there's one thing I want to say. I don't know whether – so ESRP is, again, a synthetic workload. So I don't know if they're using real emails or using some sort of synthesized data for the email payload. It's synthetic data. They're just using the jet engine. Yeah, yeah. So it may not dedupe at all.

It may not compress at all. Or it may compress down to zero. I don't know. So you bring up some interesting points about synthetic workloads. So one of the tests that we see promoted pretty heavily with all flash arrays advocates for using an unreducible data set. And I think the reason for this is because it's the quickest way that you can try to fill the capacity on a data-reducing storage platform. Yeah. But the downside to that is –

If you don't have time to test multiple test sets, you look at the edges. Right. And irreducible is worst case. Yeah. Well, irreducible I think for a platform like ours is somewhere between a 5 to 6x load increase, and I think many miss that. So if you take our basic numbers, which is right around a 6 to 1 data reduction, and if I round these just for simple math on the podcast, if I'm providing a global average, meaning across my install base, a global average of 3 to 1 compression,

that means I'm actually getting a 3x amplification on the IO back end of the storage system. Absolutely. And when you introduce a non-reducible data set and then try to drive the system to max load, you get a false ceiling on your performance. Conversely, if I have a non-reducible data set and if my D to D duplication ratio is a global average of 2 to 1 that means I'm garbage collecting at a 2x

amplified rate because I'm now having to invalidate or garbage collect on blocks for cells that I've invalidated where normally I wouldn't invalidate them until the last reference has been removed. So it's interesting how systems work with test loads. Yeah.

The problem is that we don't have good benchmarks that use quasi-realistic data. You know, maybe there's a solution here for us. Well, I've been working on it. But, you know, the email thing is going to be ready in a couple of months. That's good. That's good. I'm sensing how it's going to be, send me one of your systems. Or send two.

What the hell? Why only one? Yeah, yeah, yeah. That's true. There's replication now. There's true. There's replication now. There's replication. But, you know, if you're using the common synthetic benchmarks, you know, basically you get to choose this data is going to reduce much better than the real world and the numbers are going to be meaningless. Or this data is going to reduce much worse than the real world and the number is going to be meaningless. And between those two meaningless numbers, i'd rather have the one that's

too low than the one that's too high you know so if i if i know i need a hundred thousand iops and that worst case comes out at 120 then i'm going to go yep got overhand i'm fine yeah right you know you could go the other way and do what i'm about to complain in a blog post I've been seeing from hybrid guys where people do reviews and they use test data smaller than the flash component of the system. And I caught one guy who said, to make it run as fast as possible, I did this. Since when is it a reviewer's job to make things run as fast as possible? Don't get me started on 2 million IOPS. Yeah, well, there's that. I've said too much.

Okay. All right, back to the product. So we've got five forms of flash reduction. What else is the thing, though, besides black storage and stuff? You mentioned replication. Yeah, so we have to start with a premise of disruptive economics and I think we've seen this, as I said, grow through

the market. I think there's other design details that are interesting. So today the system is a two-node modular storage architecture and I know people are going to be, boo, boo, I want scale out.

Did you hear either of us talk about it? Neither of us did that. I was referring to your listeners. Yeah, you're right. I think the challenge with that is sometimes we as a market, you know, enamor different technologies with an assumption that they're all the same. So my assumption when talking to a customer who says, I want scale-out, particularly for block storage, look, scale-out's a requirement for file storage. Let's not even debate that.

Scale-out in block storage usually provides you a means of simplifying the management of multiple systems. But what you really want is to be able to grow your system on demand non-disruptively. And when you look at the scale-up flash systems that are in the market today, they don't all do that. I might also want the efficiency of having one deduplication realm instead of two. That's true. That's true. But I think the basic premise, I think, when you talk to a decision maker remember someone who's not as technical is you know can i scale this system without reconfiguring my hosts or my environment and i don't know that that's a constant within the current

scale at all flash arrays however our system design clearly it isn't some there there are there are definitely products on the market that have a scale-out architecture but not a scale-out implementation of that architecture. Look, when you've got to migrate your data to either scale or to add new software updates and feature sets, some of us call that beta code. Okay. All right. I got you. Down. So what we have is we have a two-node or dual-controller architecture. It is built around a stateless controller framework, meaning the controller is simply CPU, memory, and I.O. ports. This architecture allows us to introduce some really new elements into your two-node storage controller

that I don't think have existed in the past. The first is an element around performance assurance. The controllers operate on the front end as a symmetric active-active array, all ports active, all IO coming through all the ports, simple multi-path and configuration management allows us to address the SSD on the back end as one global pool. And in this architecture, we're able to actually limit the resource consumption within the controllers to half of the actual physical CPU and memory. And what this allows us to do is to ensure the performance of normal operations remains the same when I enter into a maintenance mode operation or, heaven forbid, an unplanned outage.

And this framework we call always-on is a different way to look at resiliency. It's not about just having 5.9s or greater availability in terms of if I fail a controller or pull a drive. It's about never feeling the impact of a failed controller or a pulled drive. And this is really critical as you shift from disk-based arrays that served IOs or IAPs in the tens of thousands range into the hundreds of thousands range. But this is a problem we saw quite a bit. Right. Even with those disk drive systems where, you know, sure, it's active-active controllers, but to get all the features to work, you have to run all those CPUs at 70%. And then when something goes wrong, you limp along until the Maytag repair guy shows up. Yeah, two nodes running at 70% doesn't mean that one node can run at 140.

Nope. So it's interesting, because every now and then someone will say, well, I want that tunable. And it's like, you think you want a tunable, but you actually don't. The only way that you can assure this performance is by taking it out of the hands of those who are going to put load on the system and letting the system

enforce the limit. So that's the first element there. It's around ensuring just system state and performance during normal load. And I would highlight, again, for someone interested in a scale-up versus scale-up architecture, I don't think that steady state performance is seen on any of the all-flash scale-outs today. That's to the best of my knowledge, and I'm not here to start a FUD storm. It would be maybe best that you should inquire or ask your vendor what it looks like during failure operations. During an outage or something like that, yeah.

Yeah. Sorry. Let's pivot for a bit here. So the second thing that we have from this design is we're able to actually change. Wait, wait, wait. Change. Wait, Vaughn, Vaughn, Vaughn. You said stateless.

So what happens with cache when power dies and stuff like that? Ah. Are you really saying stateless? So flash controllers don't have cache in the way that you consider a disk controller. If you're going to say cache, then you can say we have 100% cache misses because we don't have cache. If you're saying flash and you're saying performance when data is from flash is good, then we have 100% flash hits. So what I mean by stateless is there's basically two tiers within a storage subsystem. There's the persistent tier, and if this was a disk system, you'd say that's disk storage.

With us, it's flash. And there's usually a non-persistent tier where you do your write buffering. That's called NVRAM. Our NVRAM components are not in the controllers themselves. They're actually in the shelves. Okay. So that's how we make it stateless for me. And the last time I looked were flash.

Today they are flash-based. So we have the persistent and the non-persistent tiers in the shelves. And again, as I said, from a read perspective, while there is system memory, that system memory is really more of a metadata table construct and being used by the system to run and operate, not used as a read cache as you have with the traditional storage system. as well. As you update the metadata, you potentially could be causing some serious problems. So that's also flushed out to this NV RAM into shelves. NV Flash, I should say, or just Flash. Just a Flash. Go ahead and go back to where you were going. Now we do mirror, just to be clear, the metadata constructs

in the metric in both systems. So that at failover time, we're not having to rebuild that construct or reread it from Flash. It's mirrored in memory between the two. Okay. But in terms of the classic node A cache gets lost and has to be rewarmed on node B, that construct doesn't exist. Yep. has to you know gets lost and has to be rewarmed on node B that that construct doesn't exist so now that we have a stateless controller architecture what our customers can can have again that's that's unique in market is they can they can increase their performance by simply upgrading a controller in place and it won't disrupt operations, including it won't disrupt performance.

And so we've had customers move through the FA300 series. They can go through all the products in the FA400 series, and we will take this architecture forward as we go into the next FlashArray series and further. This is an architecture that we're committed to. And basically, this allows a customer, start on two controllers of the previous generation, you know, move to the workload under one of those two controllers, take one out, introduce one controller of the new generation, shift the workload to the controller of the new generation, you know, subsequently remove the second older generation controller, drop

in the second new generation controller, and they're done. And that process is completed in about 15 minutes. Again, no change of configuration on the host, the network, or anything above the stack. And so if there is no performance pain and there is no IO disruption, did anything actually ever happen? Other than the fact you updated and potentially doubled the performance. We'll still schedule it for the weekend. Well, that would be because we're conservative kinds of people.

Well, that's an element that actually when we get into these benchmarking of systems, we're a big advocate of test the system how you would operate it, meaning go through completing upgrade processes. Now, controller hardware upgrades may not be something that you can do when you receive a system for proof of concept, but you can absolutely go through software upgrades and all the other failure scenarios and validate what can or can't be done during normal operations or should be scheduled for off hours. Yeah, I agree and think that folks in parts of the hyper-converged market are going to be unpleasantly surprised with the size of the impact of failures. Yeah, you bring up hyper-converged.

It's an interesting time to be in the storage market. Oh, yeah. The volume of innovation in this space, I think, has one resounding theme, which is the incumbent storage vendors and the incremental gains that they've put in their products over the course of the last five or six years just are not doing enough to meet the new paradigms of how data is served. They were designed for single hosts mapping directly to LUNST, and these compute clusters we have, whether they're virtualized or big data, et cetera, can really bury the

traditional array, and it's great to see this innovation. Now, the question I have will be, what's the lasting effect in the market? And my analogy here would be, many of us grew up with broadcast television where we had maybe five channels to choose from. I was in New York, we had seven. If I count public broadcasting in Detroit, I had seven as well. Because I had three from Detroit, one in Canada.

And you could watch the CBC. That's right. But anyways, my point was we went from a handful of channels to cable TV and now we have hundreds of channels. And market share, in terms of program market share, really became diluted. I wonder what's going to happen in the storage industry as we go from five major players from five years ago, and we go forward. Are we going to move to 10 major players, each with smaller market shares? Or are we actually going to see a change in the guard?

Yeah, I mean, don't you see a consolidation play here at some level where big companies buy small companies and incorporate some of the technology and, you know, I don't know. Some of the big companies aren't so good at that. Yeah, some of them aren't. Some of the big companies aren't so good at that. Yeah, some of them aren't. Some of them are. Including some Vaughn used to work for. And Howard pulls out the velvet hammer.

But it doesn't mean they're going to be poor for the rest of their life in this endeavor. No. And the interesting thing is actually that the marketplace – one way the marketplace could change is for Cisco and Lenovo to decide they want to look like HP and Dell and play for real in the storage business. I think Cisco kind of has to 18 months – 18 to 24 months from now to maintain their growth rates. Yeah. I think Cisco is vested. I know Invicta is currently in the middle of a stop ship, but they'll resolve that and get back to shipping product. Yeah, but they need a broader line. But they've got a lot of weight they can throw around, and I'd be surprised if they're not going to jump into the

hyper-converged space, whether it's a la EvoRail or that was Evo, not Evil. Yeah. Or some other instantiation of DAS-based storage architecture. They dipped their toe in the water with the SimpliVity deal.

Oh, that's correct. Thank you. Thank you, Harlan. They just did yesterday another generation of servers announcement, and the only form factor that made a lot of sense from the storage point of view is they did a 4U30 or 36 drive system that would be a good ZFS box. form factor or the high density form factor like the Super Micro Super Twin that Evo Rails is modeled on. So I think they're a year from being serious even about that.

In no small part because they get a boost in the market from being the servers every storage vendor uses in their reference design because they're the only server vendor that doesn't have a storage division. Yeah, yeah, yeah, yeah. Yeah, they've made a lot of inroads with a lot of storage partners, and they have a significant presence in market. Now, what I think could be more interesting for Cisco besides storage is can they continue to grow within the Blade ecosystem as it seems like Blades are starting to become less desirable? Yeah.

Yeah, no, I think the Blade era is coming to an end. Yeah, because their market growth is strong in Blade. Because you can't do hyper-converged on Blade. Yeah, and their market growth was strong in Blade, but not in the overall server market. Right. The other interesting thing they announced the other day is a modular compute server. I didn't see that. It's got 16 Xeon E3 servers in a 2U frame.

Nice. There's no I.O. at all, just shared 40 gig Ethernet amongst them all. But it's good for more moonshot than to run VMware on. Right. For compute applications that you're going to shard across a million servers. All right, all right. We need to get back to Pure here. Okay.

Was there other stuff you wanted to talk about? The product? Yeah, so we were talking about the architecture when we kind of went off on another little jaunt. I have actually said many times that I think the fact that at first glance a pure system looks accessible to a storage guy was brilliant in terms of speed to market acceptance. Yeah, yeah. You didn't have to teach people about 10,000 other pieces of technology and why they wanted them. Yeah, I believe there's a formula to success, which is if you can make the burden to adoption low, and what are we offering? We're offering a storage device that provisions externally LUNs. You connect to them, you move your data on them, and then you measure results.

So if the burden to adoption is low and the results are off the chart, you have the formula for fantastic success. And it takes much more than just the storage device itself or disruptive economics and data reduction technologies. You've got to have a better experience through the software licensing model, the availability of the platform. And to your point, what's my operational burden? No knob turning is sometimes a little too much for some people to grab. You sit there and say, there's no RAID layout,

there's no root volume, there's no aggregates, there's no cache tuning, there's no block alignment or assignment. Yes, there's some of the data reductions in line and some is post-process. The problem is you're talking to guys who think they have a job because they're the keepers of arcane knowledge.

And now you're saying that there is no arcane knowledge, and they're wondering why they're going to keep their phony baloney jobs. And the answer is that the really arcane knowledge isn't how to tune the knobs. It's how to know what you need. Yeah, I think in terms of the role, kind of like the role of the backup admin had changed, right, with the introduction of disk into the tape world, where disk became the backup medium and tape became the archive medium. I think those who are in charge with maintaining storage, if they can start to think of their role as being the ambassadors of data and the fact that your storage systems are going to radically change this. What we're seeing today with Flash is just the tip of the spear because structured data works very well on something like a pure storage device or the other all-Flash arrays I've mentioned. But the bulk of the net new data that's being created today and into the future will be

unstructured. And that's going to probably be a better target for maybe tier two platforms. And, you know, you're going to have to learn to make a choice on those designs as well. Do I just throw white boxes at them and think that's the cheap mechanism based on open social software, and there's folks that are in that camp? Or do you say that those systems, the shared nothing architectures, have an inherent overhead of 3x footprint that works against the constraints of the data center that we mentioned earlier in the podcast, And I'm more in that camp.

So lots to learn. It just means your knowledge base as a storage admin has to change. And by simplifying what you've done historically, that's a good move. Yeah. Okay. So we're over 40 minutes here. Any last questions, Howard? No, I'm pretty good.

Okay. Well, this has been great. Vaughn, do you have any last questions for the graybeards here? Yeah, not a question, more of a comment. And for those on the podcast that were unaware,

I participated in a panel with Howard and a number of other representatives from some storage startups at VMworld. And I closed that session with the same way I would close this one, which is while we at Pure Storage believe that we're making the best all-Flash array platform, I would advocate for you to check out Flash from whichever vendor or platform you think best services your needs. Because if you can get the economic equation to that of disk, you will have a better experience in Flash than you've ever had on disk. And so, not a commercial for us. It's more of an endorsement for this medium and the adoption of it.

Well, I think that brings it all home. This has been great. Thank you, Vaughn, for being on our call. Hey, thanks, guys. This is great. And next month, we will talk to another startup storage technology person. Any questions you have, let us know. Thanks. That's it for now. Bye, Howard. Bye, Ray. Thanks again, Vaughn. See you guys. Until next time.