Grey Beards on Systems - GreyBeards talk HPC storage with Molly Rector, CMO & EVP, DDN

Episode Date: December 17, 2015

oIn our 27th episode we talk with Molly Rector (@MollyRector), CMO & EVP of Product Management/Worldwide Marketing for DDN.  Howard and I have known Molly since her days at Spectra Logic. Molly is also on the BoD of SNIA and Active Archive Alliance (AAA), so she’s very active in the storage industry, on multiple dimensions and a very … Continue reading "GreyBeards talk HPC storage with Molly Rector, CMO & EVP, DDN"

Hey everybody, Ray Lucchese here and Howard Marks here. Welcome to the next episode of the Graybeards on Storage monthly podcast, the show where we get Graybeards storage and system bloggers to talk with system and storage vendors to discuss upcoming products, technologies, and trends affecting the data center today. Welcome to the 27th episode of Greybeards on Storage, which was recorded on December 15, 2015. With us here today is Molly Rector, Chief Marketing Officer of DDN. Why don't you tell us a little bit about yourself and DDN Products? You bet. Thanks for having me, guys.

I'm Molly Rector. I'm responsible for product management and marketing at DDN. I'm also a member of the board, actually vice chairman of SNIA, the Networking Standards Group and Storage Industry Storage Group, as well as the Active Archive Alliance. I'm involved in a variety of different industry groups as well. Related to DDN, our company is just about 20 years old, and we're currently the largest privately held storage company, at least until EMC becomes part of Dell. But the focus of DDN is all around solving complex data types of problems in the data center. So whether it's high performanceperformance computing, cloud computing, large-scale analytics,

that's kind of the specialty of what my company does. 20 years? I would not have thought that. That's amazing. DDN's the biggest storage company nobody's ever heard of because... I always thought that was Fujitsu. Well, if you're a supercomputing guy, you've definitely heard of DDN. Yeah, there you go. The broader markets. We're working on that name recognition.

Between the fact that you're moving from supercomputing into the enterprise space and the fact that you're not playing the venture capital, see if I can get a trillion-dollar unicorn valuation game, you don't get covered by the tech press that's really just interested in what money is floating around Sand Hill Road. Yeah, that's definitely true. We are not on the VC curve. We're privately funded, profitable, have no debt. We're that type of company versus the external funded type of storage company. So you're right. It does raise interest of a different type of journalist. But isn't it funny how privately funded has no debt makes money is considered a bad thing by people in this business?

It's very unusual. In any other industry, that would be, oh, that's a great thing. Good for you. Yeah, yeah, yeah. So tell us a little bit about supercomputing and HPC versus what you might consider enterprise environments for storage. What are the differences you think are applicable? You bet. So in the supercomputing industry, those are the types of environments that have been dealing with thousands of cores of compute nodes trying to do a bunch of parallel work on very large data sets. And that's been something that they've been working on where petabytes of storage and thousands of cores of compute were normal to them five to 10 years ago.

And as we started to see the evolution of big data enterprise analytics, the enterprise using data strategically. So thinking about, you know, making predictive decisions on where they invest their funds, where they place product in retail stores. Data has become much more strategic in enterprises versus thinking of where we're just using data to back up and store PowerPoint files and things like that. So we're seeing business units within enterprise starting to use data strategically to make money for the business. Those seen as a revenue center versus a cost center where IT has sometimes been considered a cost center. And those business units who are using data predictably have a lot of attributes that look a lot like the supercomputing industry. Lots of cores doing lots of work on the same data in a real-time kind of perspective to make decisions. So it's a convergence thing that petabytes of data, really huge compute systems being used day by day by lots and lots of people is becoming common in the enterprise like it was

in supercomputing and high-performance computing 5, 10, 15 years ago. So are you talking like Hadoop kinds of analysis done on-prem with huge amounts of data? Yeah, it's Hadoop. It's industry-specific analytics applications. So, for example, in the oil and gas industry, they have their proprietary codes that they use to do analytics, think Hadoop, but for a very specific type of data set. Seismic analysis. Yeah, seismic analysis. And the financial services market is around high-frequency trading and backtesting. So there's a lot of proprietary applications in different markets

that do what Hadoop does, but it's designed specifically for their workload. We've been working on those analytics packages for years, and Hadoop is kind of the new commercial available enterprise product that does that same kind of work. Yeah, I noticed you had listed a benchmark from Stack, which was one of these analytics kind of benchmarks. It's kind of interesting, yeah. Yeah, so the way DDN has designed our systems has been all around performance that historically been driving very high throughput for larger files of unstructured data. But over time, we've seen that being able to do mixed IO, having a blend

of small files and large files is increasingly important. But everything in our systems from the hardware we design, which we use InfiniBand backplanes instead of Ethernet or something like that. We have embedded PCIe fabrics within our hardware chassis so that we can drive line speed to the devices, whether it's NVMe or fast SSDs, whatever it is, within the hardware. And then the quality of service to be able to scale those systems and maintain performance as you have a file system that's, say, 95% full and multiple petabytes, that you don't see much of a dip in performance in our systems, even at that really large scale.

So we've designed end-to-end, whether you're at 0% full or 100% full, you should get similar performance, or 1% and 99% are probably better numbers to use. Yeah, things always get weird when you're completely full. Yeah, or when you're 0% full. Tell me about it. So DDN has designed custom hardware for years to do high performance. We've designed custom software to do high performance. And so when you see something like a stack benchmark where we're using a spinning disk system

and bumping up against in a benchmark all flash arrays and we're still faster, it's because we have the interconnect, we have the fabric, we have the software to drive line performance of the devices we have versus, you know, sometimes significantly smaller subset of that performance. I know you said your in-cluster fabric was InfiniBand, but what did you say your storage fabric was? We use PCIe fabric embedded within our hardware arrays. That's for the inner cluster.

Yeah. And InfiniBand is the access that you provide to the thousands of cores and stuff like that. So to the thousands of cores of the cluster, we support InfiniBand, any type of Ethernet, fiber channel, and soon the new OmniPath interconnect that's coming from Intel. But then we use InfiniBand to, as you grow your cluster of storage systems, adding JBODs, adding additional controllers, we use the back-end interconnect of InfiniBand.

So when you say custom hardware, you're not talking about, you know, small box custom ASICs on the order of somebody like Violin or 3PAR. You're talking about custom implementations of x86 servers to use as controllers, right? Yeah, so we design our own 4U boxes that have the interconnect, the fabric, the specific motherboards that we need to push our different systems. So we still design our own hardware. We don't tend to use, we don't start with a super micro box in the NAT or software like most other companies do. We still do custom hardware and it makes a big difference.

You typically can see from the storage density that we can offer and the performance density we can offer, we typically use about one-fifth of the data center of a Supermicro deployment. So it really does help at large scale to drop power, reduce the number of components you're managing. Yeah, this is one of the things I wish the guys who have jumped completely on the software defined bandwagon would get. Servers are industry standards, but they're not commodities.

We're not talking pork bellies. Yeah, so it's been an interesting pendulum that if I were a small customer and only needed one or two boxes, by all means, go software defined and use some kind of commodity hardware. But when you look at large customers with, you know, potentially hundreds or thousands of network ports and racks and racks of data center equipment, that's where hardware efficiency and performance really does matter. DDN does software-defined stuff. We certainly have software options and object storage and flash systems that we'll offer

as software only, but you will never get the performance density, the lower cost per performance with commodity hardware that you do with custom hardware. Let me just clarify. You don't do FPGAs, you don't do ASICs, but you will design your own custom server hardware with motherboards that others provide and componentry that others provide, right? Correct. Well, actually, you guys spin your own motherboards, don't you?

We will do boards where we need to. We did a custom. We took the OmniPath silicon and made our own next to our storage system, which was our own board. So in some cases, we do do boards ourselves as well. So what's this OmniPath? What are we talking about here? So Intel, in their ever-growing

dominance in the data center, is coming out with a new interconnect that should be extremely low latency. Over time, we'll be designed to work with their processors with other Intel types of solutions that they're designing the firmware to optimize. If you're going from an Intel processor to an Intel interconnect to an Intel-based storage system that has that same kind of silicon within it, you'll get much lower latency than across any other interconnect technology out there. It's something that's hitting the market in about February is going general availability, both on the compute side as well as the storage side.

And we see it as the next generation of highly efficient, high performance networking capabilities. It will be bumping up against the 100 giggie as a very solid competitor for sure. My God. So we're talking lower than InfiniBand latencies here, right? That's what I've seen in the marketing collateral. Clearly, we're only talking about promises because they're not shipping it yet. No, we have some early boards and whatnot that we're just starting to test. But the promise is certainly lower latency and lower cost per performance. They will need more ports that they're, in theory, going to price it

such that you can still come in lower cost. And so you see this replacing InfiniBand over time? I don't know. Yeah, it's kind of bizarre. Yeah, it seems to me more a threat to the rack scale PCIe kind of architectures that we haven't quite seen yet. Yeah, I would say it's more what Howard is saying, and that they'll be bumping up against Cisco and 100 gig E as more of the competitor. Well, interesting times here in that space. And you see that you mentioned a lot of industry specific analytics and stuff like that.

So you see that like in the bioinformatics as well as, you know, fine serve and oil and gas and those sorts of things. Yeah, absolutely. So we and I think it's been a bit about where Intel is putting business development efforts into it that they've been focusing actually in oil gas specifically has been an area that I think several of the new compute clusters are coming out in InfiniBand based next year. So it's been a bit of a focus on which customers Intel is evangelizing with right now. Well, you know, for the past decade or so, that's kind of been the Willie Sutton theory. Go where the money is. Go where the money is.

I don't know. Oil and gas is having a hard time right now. Yeah, no, right now with 40, you know, when oil was $100 a barrel, you know, people would drill holes in anything, but at $40 a barrel, things even get tough over there. Yeah, absolutely. Though I'm sure those biz dev efforts started when it was $100 a barrel.

Yeah, exactly. So you mentioned your stack benchmark was you were competing against all flash systems with a hybrid storage or just a disk system and still doing well? Yeah, the product we submitted actually was just disk. We didn't put any flash in it. And we did that for a very specific reason that then we can take the benchmark and show the performance advantages we have. And depending on which portion, the stack benchmarks, there's a handful of different ways to look at the data. We were about two to four times faster on the different run times. And what we really

wanted to show, and we work in the financial services industry extensively, that the cost per performance is something they look at very closely. So if we can deliver great benchmark performance with as low a cost as possible spinning disk. That puts together that profile of really what the FSI companies are looking at to out-compete each other on performance and do it in a cost-effective performance sort of way. Gosh, I always figured FindServe had all the money in the world to spend on performance. Well, they do every once in a while. Every once in a while. It depends on the market.

It depends on the market. It depends on the market. It depends on, you know, exactly what the payback is going to be. Yeah, which is this cost per performance thing. You know, the other thing we see from those guys is they really want predictable performance. Having performance that sometimes is, whatever, a million IOPS and 20 gigs a second, and other times it dips to half that, and other times it's double that,

is very bad for them. They need to know very, very predictably every time they run a job that they're going to get the exact same type of performance. That's a huge deal to those guys. And the quality of service on performance is something that they do spend a lot of money on. Well, yeah, that's one of the concepts I wish we as an industry have to educate our customers about that, you know, it's consistency of performance that your users really care about. It is not peak performance. You know, that almost doesn't matter at all in these data analytics, data intensive environments.

You know, it's one thing if it's just for, you know, a backup environment. But when you're looking to use your data and run jobs all day long, you can't have some of them run in, you know, whatever, a millisecond, another take a second. That just doesn't work for the user. But, I mean, you can't do that in retail either. No, no, it's definitely not. I agree with you. Those are the areas that DDN really focuses on with our customers is really understanding their business needs. And, you know, we don't solve spec sheets a lot just because it's these subtleties

of I want predictable performance. I have, you know, a limitation of how much power I can use. Therefore, I should switch to all flash versus you're just pushing all flash because it's the latest, shiniest thing. We have pretty deep conversations in these areas with our users, typically. It's pretty unusual to see predictable performance from a disk-only storage system like that. I mean, you have to do a lot of what I would consider wide striping and data placement, you know, have a vast quantity of disks and stuff like that. You know, it's a lot easier, quite frankly,

with an all-flash system to provide predictable performance than it is in a disk system or hybrid, I would say. Yeah, I think that's absolutely true. And moving parts, you can't get around them. Something we call, and I won't go into all the gory details, but we have something we call our SFA, real-time operating system, which is the software we've written over time to be able to handle these large-scale systems, provide the predictable performance.

We use parallel file systems frequently to ensure multi-user access to the same content, the same data that's distributed over different systems. We have a quite detailed story I could go through on how we do that, but that's really the… Oh, you can't scare us, Mo. I'm sure you wouldn't be afraid. It just might be a longer conversation than you want for a podcast. I find the concept of getting the performance from spinning disk, specifically in the analytics arena, interesting because it eliminates, it means I can just leave the data there, that my cost per gigabyte isn't so large that I have to move data in, analyze it, move it back out someplace so the next batch can come in

and take over that valuable resource. Yeah, the exchange transfer thing. I think it's an area that, you know, as we look at the way the data center is changing, that we talk about data is growing very quickly, and that's certainly a fact and something we've been talking about for a long time. But the problems that the rapid data growth creates is much more than just we need higher capacity storage devices. It's not just a matter of where are we going to put it in the budget, but actually, how are we going to use it? How do you make, when you go from 10 terabytes to 100 terabytes to a petabyte

of content, how do you actually make that usable data that you can access, that your users can, you know, remote data centers get access to in a performance sort of way that, you know, I think as an industry, sometimes we focus a little bit too much on just, you know, how do you fit that data into a storage system and the budget you have, but not really how are you going to use it. And I think that's really where conversations with customers are evolving now. They have all this data. They've heard about Hadoop. They've seen some of these really cool case studies around big data and how you can use your data to differentiate your business. But now they have to now get those systems out of these big, fat, slow disk drives or tape devices, whatever is sitting on them, and make it usable. And it's a shift in the way people

are thinking, I think, about their storage systems, their networks, you know, how they leverage cloud and all of it. But making that live data usable and strategic is how businesses are differentiating anymore, it seems. Yeah, but I mean, even on the just, you know, we're going to keep this 40 petabytes of data. You've got to start thinking about it differently. You can't back that 40 petabytes up full once a week and incremental daily just because that's what you've always done. Yeah, absolutely. And that's where I've seen, whether it's object storage or cloud, whichever type of system you're talking about.

Isn't cloud just outsourced object storage? It is. It is, absolutely. There's lots more to cloud than just object storage? It is. It is. Absolutely. There's lots more to cloud than just object storage. Well, I mean, specifically as a data repository, yeah, there's a... Once you add compute at the other end of the

cloud, things get different. I'll give you that. But, you know, it's like the choice between WAS from DDN or S3 is, you know, do I want it in my data center or do I want to pay somebody else to manage it for me? The other challenge with, you know, S3 is getting petabytes of data from some data center to, you know, AWS is eons. I mean, it's not trivial.

It's not trivial. And those are the things that I think customers are starting to evolve from. Well, I can't just do my traditional backup like Howard was saying on my petabyte or 40 petabytes or however much content they have. They need something else. And then they go dip their toe in the water and cloud. And for certain use cases, and if you have a huge network pipe and, you know, if your data is not changing a lot, maybe that makes sense for others. If you retrieve data frequently, sometimes it's too slow, sometimes it's too expensive. So there's just a lot of learning for customers. We have these new technologies out there. We have these technologies to be able to have a huge archive that can do two and three and four copies to do data protection within an

on-premise object store. We have cloud. We can integrate the two. You know, there's just a lot of new technologies customers are grappling with that as their data sets grow and as they're looking at using their data in a more strategic way that they're all evaluating right now. Does DDN support a cloud service offering or is it you're just talking about cloud in general

as a technology? Oh, certainly. We have many different cloud approaches. We have public cloud providers that use our object storage technology as part of the structure. Our own WOS object store can be hybrid where it can export a copy into a public cloud, making a nice hybrid storage offering. And we also do have cloud services we offer based on our technology, DDN-branded cloud service offerings where we'll manage on DDN storage with DDN WOS, DDN high performance, and connected to a supercomputer and be able to offer complete DDN-branded cloud offerings as well.

So we do cloud in a lot of different ways. God, infrastructure is so – and you actually have a supercomputer grid that somebody can actually rent out on an hourly basis or something like that? We do. It's not quite nearly as flexible where Ray can take his credit card and spin up a supercomputer for an hour like you could on AWS. Oh, darn. It's not quite that flexible. However, yes, essentially the way we go about it is if you look at the computing capabilities in AWS, they don't have a commitment to the performance quality of service that, you know, how the latency, as you start to really get into

very specific requirements of the compute part of AWS, it's not like a supercomputing environment, and nor should it be. Most customers don't need that. So what we've done is we partner with our supercomputing customers who have 15%, 20% of a very large supercomputer. These are top 10, top 20 supercomputers that are available, and then we place our storage local to it. We set up a mini supercomputing site,

and we give access to that environment to users. Usually the entry point sits at about 100 terabytes of data that they need to do work on to be a nice entry point into that environment. But, yes, you get the performance of a top 10 supercomputer on DDN high performance storage, including Waz Archive. And it's for those users who need that kind of performance, it's just absolutely fantastic. You see that use case with auto manufacturers and folks that are the guys who are using that service. I was just thinking of firing up the computational fluid dynamics application

to see if it's really worth it to heat the office at the lab from the hot aisle in the data center. Supercomputing. Renewable supercomputing in the data center. Supercomputering. Rentalable supercomputing. I am impressed. Supercomputing on demand is the next big thing. Yes. Yeah.

Gosh. It makes sense because there are applications that the runtime is dramatically affected by all those different performance pieces within the system. And lots and lots of users have a job that maybe they only need to run four times a year, and you certainly aren't going to buy a supercomputer to do that. But being able to run those jobs on a supercomputer when you, you know, whether it's CAD design or you're looking at in the aeronautics industry

and you're looking at failure analysis and you get a new set of data, it makes a lot of sense to be able to lease this stuff out for a temporary amount of time. Or maybe you leave your data up there and you just only run analytics or run jobs against it every quarter or so, and we see that as well. That's pretty impressive, Molly. I'd never heard about that. I'm sorry to hear. Like Howard said, the best- known company you've never heard of. Okay, so let's take a quick tour through your most significant products, because I know there's 4 million altogether. We've talked a little bit about Waz. Waz is an object store, right?

Yep, absolutely. So like most other object stores, I assume that it's a shared nothing x86 cluster of, you know, at the small end, 10 or 12, at the large end, a couple of billion nodes to which I can pump data, right? Yeah, yeah, that's all accurate. There's no databases and no file systems built into Wwise. It's really the only pure, true object store that doesn't have a bunch of file systems built within it that are then abstracted out into an object layer. We all had different approaches and patented different approaches to object storage, but ours is completely pure. No structured data, no file systems built within it. But you know what's really interesting with object storage these days is it's a great big fat pool of data that can store unstructured data almost limitlessly. And it can use networks efficiently to move data between data centers. really are looking for is complete packages now that Waz can be deployed as an active archive where it has all the archive software built into it to manage those objects. Or there's one policy where you store in this node for a year and then you put a copy in public cloud for three years and maybe a copy on tape for five years. It does the data management and certainly uses the object storage as a big portion of that storage.

But that's really what we're seeing. Customers want more and more that they want the object store to be smart and solve problems. It is the archive manager. It is the Dropbox functionality. So you can do file sync and share. And they want to buy an object store and have it come with those kinds of features and functionalities, which is where most of the growth we see in object storage coming from right now. So you're working with partners that do the data mover for the archiving or that put a

sync and share front end on it for you? Or are you guys developing that yourselves now? Yeah, the data movers are DDN developed. The sync and share is done through a partnership. Mobile device backup is done through a combination of DDN and partner technology that we co-developed. So a bit of a mix, depending. We're continuing to do more and more of it in-house or through some kind of joint development agreement with a partner. Cool.

Interesting. Is it available as a software-only solution as well as, you know, a complete package? It is, yeah. So Waz and all the features that Waz have can be sold as software-only or as a pre-built appliance, depending on what the customer is looking for. Okay, and if I remember right, I can choose between N-Way replication and erasure coding for data protection? Yes, that's a good memory. Or you can do both. But yes, we have all those choices.

Okay. Does that extend all the way out to dispersal coding, where one set of erasure coding is cognizant of multiple data centers? Nice, nice. Yes, absolutely. Yeah. The multi-data center aware is a critical part of WAS that being able to have multiple copies or disperse your erasure coding across data centers and then recover from a failure, even if you lose a complete data center. That's a lot of the magic of the way the object store works for DDN. I think if you lose a whole data center, that's a little bit negligent. Yes, or somebody who was doing something very naughty out in the world.

Yes, well, unfortunately, we know how that happens. So where does Wolf Creek fit in all this? Yeah, so Wolf Creek is the engineering code name for what we now call our 14k product line. And it's the latest generation of offering. It will be the next product that we put up into the stack benchmarks and certainly will, unless there's something surprising that comes out before then, it will leave the stack benchmarks for 2016. But it's a really cool system. It's hyper-converged in that you can run your applications locally,

whether that's your virtualization VMware Citrix applications or a custom application like some of the other things we've been talking about on this podcast. It's run locally on the same PCIe fabric that your SSD or NVMe devices are on. So very, very low latency, very, very high performance within the system. And you can do hybrid storage off to your spinning disk in it as well. The performance attributes of it are pretty fantastic. You can get up to 80, probably 100,000 VMs in a single 4U system. So bootstorms in very large environments are handled extremely well. If you're looking at more of just an unstructured data repository, you can scale to 60 gigabytes a second in 4U, or that's getting close to a terabyte file system in about one and

a half racks. So it's very high performance. But even more important is driving that convergence of getting your applications local to your storage and your file systems closer and closer together. And, you know, that lowers operational costs, fewer things to manage, single management GUI to manage most of your environment. The things we were talking about in the beginning of this environment of why would a customer care about hyperconvergence and why would a customer care about high-performance hardware all comes down to you can get a lot less latency, a lot higher performance, and a lot smaller footprint with this 14K platform. So are you really pitching that 14K platform

to compete with the SimpliVitys and Nutanix's of the world? Similar message, but I would say DDN will always be on that kind of top right-hand corner as far as performance. What DDN does is solve data-intensive problems for data-intensive users. Go to an SME and deal with, you know. Right, you're not trying to sell 500 of them for 500 branch offices at State Farm. Yeah, exactly, which is what a lot of those guys have done very, very successfully. However, where you get to a large-scale environment where we're already perhaps handling their archive and their unstructured data and their analytics, and they also have a VMware need,

certainly being able to support VMware on our systems helps IT on having fewer vendors to work with. Or in the environment for those very, very large users who are running thousands of VMs and really struggling from an IT department to manage it all in a performant way. That's really where we're focusing. So same general market as those guys, but we're looking at the data intensive side where they're looking at more kind of the commodity driving costs down for smaller customers. So they have a lot more customers they're targeting. We have kind of a specialized approach. Right. And there's definitely a need.

If you look in the defense industry, government, some of those areas, there's a really big need in that area. And, you know, those are the customers that you already have contact with. Exactly. And they're saying, why can't you handle our VM storage as well? And now we can't. Okay. So is the overall DDN plan to do more and more of that group of customers' business, or are you trying to poke out into the commercial space as well?

Well, we actually, over half of our revenues now come from the enterprise commercial markets. So there's that of the new hardware, new revenue, new customers we booked this year, that's over 50% now. So I do see that continuing to grow. Okay. And is that through primarily Waz and Wolf Creek, which are our scale-out NAS systems that are often displacing an Isilon or a NetApp that has been in place. And the customer is going and looking at their three- to five-year refresh. And their data performance has grown to the point that they're maxing out those technologies and what they can do. And they'll live to DDN in those areas. We sell a lot of all-flash arrays, both in the edge cloud market

as well as in more traditional use cases for very high performance. So, you know, the customers who are looking at a large Pure box, you know, that new system that Pure came out with this year where they actually went to proprietary hardware, interestingly enough. We bump into them pretty frequently in the all-flash market, and those are typically enterprise users as well. Yeah. We bump into them pretty frequently in the all-flash market, and those are typically enterprise users as well. Okay. And with WOS for archives, certainly.

What's the code name for the all-flash? A code name. What's the product designation for the all-flash array? So we have our 12KXI, and we have our IME 14K, and we have a 14K. We have three different all-flash products, and then we have a 14K. We have three different all flash products. And then we have our 14KXI. Lots of letters and numbers to keep track of. So we have three different all flash arrays that have different attributes to them as far as the 12KXI was just being used for edge devices.

It did not have deduplication and compression built in. The 14KK based product does and also has the VM support. And then the IME14K is a play around IO optimization out of the compute environment. It's a very intelligent software that's designed to accelerate IO. And when you have malformed IO from lots of different applications, all writing data differently, it realigns it to optimize for your storage. So IME 14k is a bit different. Okay. And are those all scale out architectures? Scale out in that they can become hybrid or scale out in that you can... Scale out in that I can cluster multiple together. Those are all scale out from that perspective. Yes. Cool. I have Gartner on the mind from being

at Gartner last week. Yeah. You have to be careful about how they corrupt your mind yes i've been out there for the last week i'll leave it at that yeah so tell us a little bit more about the grid scaler and exascaler solutions yeah you bet so grid scaler and exascaler are scale up now solutions both of them are designed around being able to offer scale starting anywhere from a very small plug and play appliance starting at about two or three hundred terabytes where it comes pre-configured nicely designed install in a couple hours and you're up and running with a nice NAS environment that can scale up into the petabytes quite easily can handle concurrent users in the hundreds to thousands or even tens of thousands of users, depending on how it's designed. All of our scale-out systems

are designed to do data management to WAS, where the tiering is SSD, spinning disk, out to WAS, all in the same namespace, all managed by the same data management application. So for a user and an IT guy, as they're looking at a year from now, they need to add some SSD, no problem. They can add it in the system, and the users don't have to change their behaviors. Same things with adding archive, whether it's WAS or we support tape now as well in that namespace. We can move that data out to WAS and tape as an active archive, and the user still sees the file in the same location they've always seen it within.

It's just been moved to further off, lower-cost storage. So our scale-out NAS systems are really designed to be very high-performing on the front end and do all the end-to-end data lifecycle management over time. And so does the NAS itself migrate data off to Woz or do I need to have your archiver data mover there as well? The NAS itself, for all practical purposes, of course, we have lots of software running within the system. But yes, it's just one NAS system. You set it up, you have one interface that manages it. But I can set a policy that says these are user home directories and any file that hasn't been touched in a year migrate off to Oz. Exactly.

And the distinction between the grid scaler and exascaler is size? Yeah, it's the features that you need and the size. So exascaler is designed to support a larger number of users, but it has fewer data management functionalities built into it. So if you just care about the number of users and the performance and you need to go to really extreme scale, we push the Exascaler. If you don't need extreme corner case performance or you don't have hundreds of thousands of users, we tend to push to the Gridscaler because it has more data management capabilities. Of course, you know, you lose a little bit of performance every time you add software

and data management to the environment. So that's why the difference. We've kept one that's really optimized just for performance and another that's optimized for having more data management and that 98% of the world still exceeds their performance needs anyway. Yeah. This is a very rich product portfolio for such a private company like you guys. Well, they've had 20 years to work on it, right? And we do have almost 700 employees.

Company's been growing in double digits for quite some time. So it's a pretty healthy company. I want to get back to this malformed IO. What exactly is that, Molly? Malformed IO. So if you think about the applications that create data, this is actually very interesting to me personally, that you think about applications that have been out there creating data for 20, 30, 40 years that were all written by developers in different code languages and for different needs over time. Those guys have since retired and are living on beaches or up skiing in the mountains or doing whatever they're doing. And those codes aren't being updated anymore, but yet they're still being run in various industries to, you know,

whether it's seismic processing or financial services like we've been talking about, those are still creating data. And then you have this new generation of applications being developed by web developers and the kids coming out of college who like web tools and web programming languages. And ultimately, you have these storage systems that have to be able to store the data from both of those. And the way they write their I.O. is dramatically different as far as the size of the I.O., how it runs the systems, and it's all being merged into this big thread into a storage system. And what ends up happening is your file system is really thrashed from it, that you have different I.O. patterns coming into the system.

The file system accommodates one, then has to switch to another, and you get terrible performance. But they told us that that's what the logs would solve everything. Log-based structures will solve all my problems. So that's what you see in the real world where you have a system that's sitting in a data center, this big old one petabyte system that 30 or 40 applications are writing to. And the system is designed to provide 20 gigs a second of throughput and is actually only getting two gigs a second. It's often because of this thrashing between the way different applications were written and how the I.O. is going to the system. So

what we do is we have essentially this shim, which we call IME, that takes advantage of SSD. Right now we're using NVMe primarily and some smart software. You move all that I.O. to the NVMe layer, reorder it so that it's optimized for the NAS system sitting behind it. And so that when you push that data off to the NAS, it's actually optimized right in the way the file system expects it to be. And you can get your designed in, you know, close to line performance of your NAS box. So it's just all a matter of if you have one application optimized for your storage system, everything runs beautifully. But very rarely is that the case in the real world. So having a way to fix that problem, you know, these 50 year old enterprises that have lots and lots of historic applications, and they really struggle with this problem.

And so smart software, and this is where software defined, I think, really will take hold in the future. Having smart software that can fix that problem, you don't have to change your applications. You just need to add this IO fixing layer. It makes a ton of sense in the data center. I was going to ask, you guys don't support mainframe or anything like that, do you? Because I've written some of those programs on mainframe. No, we're not really in the mainframe market, to be honest. That seems to be an IBM sweet spot. So is IME a bump in the wire?

A bump in the wire. What do you mean by that? Well, does it intercept NFS requests before they get to the NAS? It does. So it intercepts POSIX commands or MPI-IO and simply just intercepts, reorders them, and then pushes them to whichever, whatever the NAS box is, whatever that kind of file system protocol it is. It optimizes for that before pushing it down into the storage. So yeah, absolutely. It's a POSIX interceptor. And if it's full or if it's offline, the data, the POSIX commands can still just go straight to the NAS.

So you don't have to worry about, you know, you're introducing potential problems in the environment that IME can. Right. And you don't have to deal with the problems that many of the NAS virtualization systems had, where once you put them in, the data on the back end wasn't stored in any logical fashion that humans could understand. Yeah, that's a core requirement here, that you can pull IME out and still access your data, no problem. It's just designed to intercept and optimize in the data flow. Okay. Tons of interest. That's the product that we're getting more interest in right now, kicking the tires,

than anything else in the product offering that as you look at how do you take advantage of all flash arrays and BME devices, all these different things. If you want to use those devices optimally, you need to be able to push the data into cache and then push it off into persistent storage as quickly as possible. And if you're not doing something to fix how quickly you can write to persistent storage, you can't empty your cache fast enough. And when you recall the data, the reads are very slow. Yeah, I've seen some suboptimal designs

come from customers. Yeah, I'm sure. Yeah, the cookiest one was, I talked to a guy who was running a write-back cache at the server side. And after two or three days, the system started slowing down, so he decided what he really needed was just more cache. I was like, but no, the cache is never draining.

Yeah, that sounds like a very similar, very familiar problem. Yep. Okay, we're running a little bit over here. Do you have any last questions for Molly? No, I think I got it. Molly, is there anything you'd like to say to the audience? You know, if you really are looking at data growth and data-intensive problems, DDN offers free half-day on-site data analysis where we can come in and look at your I.O., your data center, and look at how can we really make it more efficient.

And we love doing this for users. So certainly feel free to submit a request. We have this offer on our website, and we'd be happy to introduce the concepts to you. Do you need, like, a petabyte of data to be, you know, such a thing? I was thinking, you know, I'd do it myself, but I don't think I have a petabyte. If you have a couple hundred terabytes, then it's definitely worth having the conversation with us. I always like doing that kind of thing as a consultant because you'll always find something. And when you find it, that's good for the customer.

Is there anything going on in SNEA or Active Archive Alliance that you'd like to talk about? Molly, I mean, you seem like you're involved in everything in the world here. So within SNEA, they have some really cool new things coming up around NVMe-based fabrics and NVMe fabric technologies and standards in that area where you can run NVMe across a fabric like it's local. Kind of interesting work being done. It does sound very interesting. It has really interesting ramifications for scale-out high-performance systems. It does. It does. So I'm quite keen on that work that's being done.

Within ActiveArchive, most of the work being done right now is really around being able to integrate the different tiers into an archive. So you have an object store from DDN and a public cloud from AWS and a tape library from Spectralogic. And how can you really make that archive work together and transparent is something that users are really increasingly asking us for, that they don't want to standardize on one vendor for their archive for long-term reasons. And we're working in that area on the active archive side. Wow. Lots of interesting stuff coming.

Very good. Yeah. Well, this has been great. It has been a pleasure to have Molly with us on our podcast. Next month, we will talk to another startup storage technology person. Any questions you want to ask, please let us know. That's it for now. Bye, Howard.

Bye, Ray. Bye, Molly. And until next time, thanks again, Molly. Thanks for having us. Thank you. Thank you. Thank you.