Nutanix Weekly: Nutanix Unified Storage: Ideal for High-Performance AI and Modern Data-Intensive Workloads

We recently commissioned International Data Corporation (IDC) to evaluate the use of Nutanix Objects Storage for modern, data-intensive workloads. IDC examined the evolution of Object Storage which has ranged from cold data repositories for backups and archives to newer, high-performance object stores for data-intensive workloads. The study also involves insightful interviews with Nutanix customers who are using Nutanix Objects Storage for analytics workloads.

https://www.nutanix.com/blog/modern-data-intensive-workloads-requiring-high-performance

Host: Phil Sellers (@infraphilip)
Co-Host: Harvey Green III
Co-Host: Jirah Cox
Co-Host: Ben Rogers

Transcript

Hello and welcome to another episode of Nutanix Weekly XenTegra Podcast with context, as all of our Podcasts are, we try to bring real world into the things we talk about here. Joined again today with my co-pilot Mr. Harvey Green, CEO of XenTegra-GOV.

2
00:00:23.300 --> 00:00:26.429
Harvey Green III: Good afternoon. I'm doing well. How are you

3
00:00:26.600 --> 00:00:32.559
Philip Sellers: doing? Good doing good? We've also got our friends from Nutanix joining us. Mr. Jirah Cox.

4
00:00:32.710 --> 00:00:33.720
Philip Sellers: how are you?

5
00:00:34.220 --> 00:00:37.699
Jirah Cox: Everybody. Thanks for having me. And so thank you. Gary, off.

6
00:00:39.000 --> 00:00:39.990
Harvey Green III: Good.

7
00:00:41.170 --> 00:00:42.989
Philip Sellers: And Ben Rogers, how are you doing today?

8
00:00:43.190 --> 00:00:49.999
Ben Rogers: I'm doing well, man, I'm looking at the barrel of a busy week. So I like being busy than bored. So I'm I'm doing well today.

9
00:00:50.340 --> 00:00:59.630
Philip Sellers: Yeah, that is a better way to spend the time, isn't it. So Ben Rogers, our sales counterpart over at Nutanix Enterprise focus.

10
00:01:00.350 --> 00:01:03.620
Philip Sellers: He's out there wheeling and dealing on a daily basis, right?

11
00:01:03.910 --> 00:01:17.449
Ben Rogers: Trying to educate customers is the biggest thing you know. I mean lots of questions in the industry about directions right now. Uncertainty with competitors. It's it's a good time to to be working for tanics. So

12
00:01:18.590 --> 00:01:35.650
Philip Sellers: yeah, I imagine so. A lot of uncertainty in the marketplace right now. A lot of people who are fearful. That's not exactly what we're here to talk about today. We're here to talk a little bit about some unified storage object storage to be specific.

13
00:01:35.680 --> 00:01:45.290
Philip Sellers: we've got a great blog post for everybody today. It's called duty unified storage ideal for high performance. AI and modern data intensive workloads.

14
00:01:45.370 --> 00:01:52.010
Philip Sellers:  so yeah, I know as a consumer before coming to

15
00:01:52.120 --> 00:01:55.389
Philip Sellers: XenTegra object store was one of those things

16
00:01:55.630 --> 00:02:01.600
Philip Sellers: where I struggled a little bit to understand. Use cases initially. So this is one

17
00:02:01.940 --> 00:02:18.920
Philip Sellers: that kinda helps us understand a few more new use cases object store sometimes gets lumped in with backup. And people think of it as a great place for storing backups or archives. But here we're talking about high performance AI and modern data, intensive workloads. So

18
00:02:19.070 --> 00:02:30.570
Philip Sellers: blog post today is written by Sam Tash ceruvo from Newton's. He's product marketing manager for unified storage.

19
00:02:31.410 --> 00:02:48.880
Philip Sellers: So let's dig in Jira, I guess. Beginning of this blog post. It talks a little bit about an Idc  research that that I, DC is done around object storage and the suitableness for certain data. Intensive workloads.

20
00:02:50.570 --> 00:03:03.639
Jirah Cox: Yeah, I mean, I like the way that the study is framed with it kind of meets people where they're at. Specifically, this calls out, in course, you know, like Col, data, repositories, backups, archives, right? Like use cases that we are

21
00:03:03.700 --> 00:03:08.660
Jirah Cox: pretty accustomed to associating with like object storage targets.

22
00:03:08.690 --> 00:03:25.269
Jirah Cox: But actually talks about, hey? But also, what are the impacts here for stuff that's like, actually quite data, intensitive higher performance, right? Like, really more like powering like a line of business type, software, and decision support software, which is kinda like, not what most people think about

23
00:03:25.720 --> 00:03:47.759
Jirah Cox: commonly think about object storage, right? And maybe the help level set for the audience right? There's an analogy that when we launched objects we we put in a lot of our like customer education decks around like, what is this thing? What do I use it for? Right? And to kind of walk through like the that sort of hierarchy of storage. Right? You got like your block storage right where you just give something a disk and it formats it.

24
00:03:47.830 --> 00:03:58.990
Jirah Cox: and that's kind of more akin to like. I just build a giant parking lot, and I go park every car there myself, and I have to go. Remember where I put every car on the lot to go get it back

25
00:04:00.100 --> 00:04:11.639
Jirah Cox: for more like your more like a data share platform right? Like Nfs. Smb file shares right? More like a parking garage, right like. I tell all the blue Suvs. Hey? Look!

26
00:04:11.650 --> 00:04:19.100
Jirah Cox: All y'all should probably be on level 3, and there's some high level sorting there, or I impose some kind of structure, but it's not rigidly enforced.

27
00:04:19.140 --> 00:04:23.080
Jirah Cox: and hopefully everyone's complying with where I tell them to put their stuff. But I can't really tell

28
00:04:23.420 --> 00:04:27.810
Jirah Cox: with with an object store, right? Which is what's going to power our composition today.

29
00:04:28.090 --> 00:04:50.770
Jirah Cox: There's more of a construct of like like a valet, or like a coat check right like I give you the piece of thing I want you to store for me my coat or my my car, I get a claim check back, and when I come back to you with my claim check I get my thing back in the middle. I don't care where you put it right. It might have been far away from me, but I mean close to me. Might have been non hot, so hot, storage, cold storage. Don't care. Don't know

30
00:04:50.920 --> 00:05:02.989
Jirah Cox: when I ask for you for it. Back I get it back right within certain sla's, and it's all governable, of course. And and I can direct the data on the back end for where I want stuff to live, but that

31
00:05:03.090 --> 00:05:05.590
Jirah Cox: sort of intelligence built into the storage system.

32
00:05:05.690 --> 00:05:27.139
Jirah Cox: Let's it do a couple of neat things. The first one. Why object storage got so popular is, of course, hugely scalable, right? Like it's just vast vast file systems to lots more opportunity for security, right? When when we need stuff like a a like a worm type pattern right? Once read many. But beyond that, once performance joins all those features at the party.

33
00:05:27.150 --> 00:05:30.469
Jirah Cox: This is where it gets really interesting for

34
00:05:31.250 --> 00:05:33.350
Jirah Cox: for applications and for our customers.

35
00:05:34.550 --> 00:05:46.140
Philip Sellers: Yeah, it. It's striking to me that you know, this is a very different type of storage. You talked about block and file shares, you know, and and the analogy to a parking lot and a parking garage right?

36
00:05:46.290 --> 00:05:53.750
Philip Sellers: The the other thing that strikes me is different is this is very cloud centric. You talk to it with an Api interface. Right?

37
00:05:53.970 --> 00:05:59.230
Philip Sellers: You're not using kind of a legacy protocol like we would with

38
00:05:59.320 --> 00:06:02.040
Philip Sellers: block or file, you know, Scuzzy or

39
00:06:02.340 --> 00:06:12.670
Philip Sellers: S and B or Cifs, or whatever we want to call it. Today, you're you're talking to a modern cloud type. Api. So this is a different animal. Right?

40
00:06:12.890 --> 00:06:27.369
Jirah Cox: It's a great point. Yeah. Born born in the age of the Internet, right? Not adapted to it meant to be exposed and and and used over the open Internet, right? Not requiring stuff like Vpns and other kind of protection like you would typically put behind

41
00:06:27.390 --> 00:06:28.680
Jirah Cox: behind

42
00:06:28.900 --> 00:06:39.989
Jirah Cox: a file system. Hopefully, no one's putting block storage. We're all out on the Internet. That'd be pretty interesting. But yeah, totally, a very, very modern. Take on on data storage. And people.

43
00:06:40.560 --> 00:06:59.310
Philip Sellers: Yeah, so, Ben, I'm curious here from your perspective, I mean, as you're working with your enterprise customers, you know what sorts of workloads and things are they talking about that they kind of align with object store that maybe people aren't even thinking about? Well, before I answer that I first want to kind of.

44
00:06:59.410 --> 00:07:24.039
Ben Rogers: you know, back come back to one of things Jyra said he was talking about how Nus really does 3 things, and one of those things is objects. This is all part of the goodness of the new tanks platform. You know, when I talk to customers about new tanics, and they go. You know what difference you from your competitors. One of these things is. We are very cloud, like from a platform itself, from the ground floor. And so for us to roll out, you know.

45
00:07:24.940 --> 00:07:47.610
Ben Rogers: file services, block services. And now object services. That's just a continuation of that cloud foundation, that platform that we created. And one of the things that Jyra was talking about is our ability to scale. And you know how we scale the clusters today is the same way that we're gonna scale the object store. It really doesn't change. So when I'm talking to customers.

46
00:07:47.610 --> 00:08:11.759
Ben Rogers: one of the things II really have to get in front of them really quick is that this does not change what you're doing today. This is actually an additional service part of the platform that you have, and what customers end up doing is they breathe the sigh relief, because all the rules that go along with the new tanks, clusters, whether on Prem in a data center at edge. Or, you know, in the cloud. Now.

47
00:08:11.990 --> 00:08:38.309
Ben Rogers: it's the same platform. And so when I'm talking to customers. Really, what I try to drive into them is that this is the platform that you've known and love for a different time. This is just another another set of services that go on that platform. What I am surprised, as you know, is looking through this from a customer's eyes. My day of directing. You know it shops is now that we have the ability to start talking about object store when it comes to containers

48
00:08:38.309 --> 00:08:50.370
Ben Rogers: and giving that flexibility coming there. And that's where you know that is a differentiator. Now we're able to use this api driven, you know. I don't say cheap storage, but you know I mean.

49
00:08:50.570 --> 00:08:56.940
Ben Rogers: not expensive storage, and start to make it, you know, manage higher intense data loads.

50
00:08:58.100 --> 00:09:13.119
Philip Sellers: Yeah, it's a good point. I mean, you know, most traditional storage we're talking about has some sort of a finite limit, you know. You're either limited by your controllers. You're limited by your dispool. There, there's some limit, and then you have to add another.

51
00:09:13.200 --> 00:09:23.639
Philip Sellers: This is a logical thing that expands infinitely and particularly on a platform like Newtonics. You you just add another node, and you can scale out

52
00:09:23.840 --> 00:09:30.470
Philip Sellers:  But that's true for object store when you're talking about a hyperscaler, or

53
00:09:30.480 --> 00:09:37.639
Philip Sellers: you know any other implementation as well. You know it goes to really large use cases which I think is a huge benefit.

54
00:09:37.710 --> 00:09:56.659
Philip Sellers: Particularly when you're talking imaging data sets or healthcare or places like that Harvey, what about you? From a Gov perspective or from a a sled perspective? Our our organization, starting to look at object store to solve some of their problems there.

55
00:09:56.670 --> 00:10:05.940
Harvey Green III: Yeah, definitely, a hundred percent and having an option like this where where they can choose to be flexible and or get

56
00:10:06.140 --> 00:10:17.519
Harvey Green III: object storage on Prem, and still have that be what they're using. And get some of those cloud characteristics as a big deal.

57
00:10:18.040 --> 00:10:21.249
Harvey Green III: There's there's a lot of

58
00:10:21.460 --> 00:10:32.239
Harvey Green III: regulations, lots of rules, things like that that are still in place that prevent some of these entities from being able to just utilize cloud all the way through

59
00:10:32.330 --> 00:10:43.910
Harvey Green III: or specify where it has to be in the cloud, or just add some complexity that they don't necessarily want to have and keep up with. This is a very good option for them to choose, and

60
00:10:44.080 --> 00:10:48.570
Harvey Green III: be able to to have a lot more control over where the data lives.

61
00:10:50.540 --> 00:11:05.789
Philip Sellers: Yeah, I mean, Jira, I'm I'm really curious about some of the benefits the the blog post kind of goes on to talk about some of the benefits here for new tenants. Object storage. Can you help walk us through some of those

62
00:11:06.730 --> 00:11:13.849
Jirah Cox: absolutely within a key one here, right scale. So just like with virtually any other workload on Titanics.

63
00:11:14.060 --> 00:11:18.939
Jirah Cox: that option's open to start small and then grow to the size required with objects

64
00:11:18.980 --> 00:11:48.899
Jirah Cox: that that growth to size required can be truly massive. Right? We're talking multiple petabytes. You can even have objects, spaces that not only federate amongst each other, but each namespace can even consist of multiplex clusters. Right? So I can bring dozens and dozens nodes to bear all within 1. One objects s. 3 namespace, which is just absolutely the technical term, is ginormous. It gets really really big, real fast.

65
00:11:48.920 --> 00:11:53.659
Jirah Cox: but but then, what can, of course, do for you right? So a really cool

66
00:11:53.800 --> 00:12:10.020
Jirah Cox: 1, 2 punch is is validation that we call out here for validation with both vertica and snowflake for analytics platforms. But even more of like a yes, and really really cool enhancement. There is the ability to then query against the data set

67
00:12:10.580 --> 00:12:24.610
Jirah Cox: from platforms like Snowflake, right, so that now I can do fun stuff like let's carry through my coat. Check analogy. If I own all the coats right. I'm not taking anyone else's coats. Here, I could say, bring me all of the brown coats size. Excel

68
00:12:24.640 --> 00:12:33.809
Jirah Cox: right not bring me all the codes, and I'll sort through them, and then give you back the ones that I don't want, or or whatever just blast them out of cash.

69
00:12:33.860 --> 00:12:59.450
Jirah Cox: I don't need a firehouse of data back. I can get the exact data set back that I want right? I can run a query, forgive me all the customers that we're tracking in in these certain zip codes right? And get back just the targeted data set that I'm looking for. That lets me get to an answer faster for the business. Even faster, maybe even coming off from like colder tiers of storage. Right? So that's pretty pretty cool there.

70
00:13:01.720 --> 00:13:17.159
Philip Sellers: Yeah, I mean, one of the other used cases here, which I think is interesting, is splunk. Do you have a lot of enterprise customers talking with you about Splunk at this point, ben anybody kinda talking from? You know that sort of

71
00:13:17.460 --> 00:13:22.779
Philip Sellers: solution or use case. I mean, the analytics makes sense that that gyra mentioned for sure

72
00:13:22.980 --> 00:13:39.370
Ben Rogers: it does. And and you know, you have to be careful. Cause Splunk is a partner of ours, but at the same time could be competitors in some spaces, but where customers are really talking us about is if they've got splunk in the cloud and that cloud storage cost.

73
00:13:39.370 --> 00:13:59.539
Ben Rogers: We've got some customers that are looking at this potentially being a place where they get land, this block where they would get higher performance at a lower cost. Me. Personally, some of those conversations are, you know, in the infancy, and then start. But this is one place where we actively have customers going. Hey? How can you help me bring my storage

74
00:13:59.800 --> 00:14:25.100
Ben Rogers: down in the cloud version of Slong. So again, it's a place where customers are looking at their options and our platforms able to to provide those options as well. I also think it's interesting when you're looking at. This is the amount of third parties that are starting to invest on the platform, you know. You see, Snowflake doing this man. You see them a lot in the market and see them a lot in data analytics. And so for them

75
00:14:25.470 --> 00:14:33.659
to partner with us on this. It, you know, excites me because they're seeing the value of it. And there's they're actually extending that to their customers.

76
00:14:34.630 --> 00:14:46.919
Philip Sellers: Yeah, I mean, you make a great point with the the names. I mean, just here in this one blog post. You're talking about a lot of the the standard sort of solutions in the analytic space. You're talking.

77
00:14:47.170 --> 00:14:48.900
Kafka.

78
00:14:49.020 --> 00:14:55.020
Philip Sellers: you know Vertica Snowflake. you know the Apache Spark project

79
00:14:55.080 --> 00:15:01.790
Philip Sellers: support for a lot of different choices. Which is great, too, I think, for our customers. Right? I mean.

80
00:15:02.300 --> 00:15:13.529
Philip Sellers: I I'm a huge advocate for having choice when it comes to, you know your platforms and how you you choose to go to market or solve your business problems. I guess.

81
00:15:13.810 --> 00:15:16.340
Philip Sellers: So, yeah, I mean, this is

82
00:15:16.700 --> 00:15:30.119
Philip Sellers: almost a universal thing that that's one of the things that I try to talk with customers about, who are having a tough time, maybe understanding S. 3. And you know their choices out there that you know that's become kind of the standard way to talk.

83
00:15:30.230 --> 00:15:36.380
Philip Sellers: And so having that strong support opens up a huge amount of options for you.

84
00:15:36.460 --> 00:16:05.090
Ben Rogers: you know, in the in the and we are building security platforms around these tools. So we have data lens, which is a great product. We're not quite there with the technology yet to be able to analyze object stores. But that's in the pipeline. So you know, I'm able to look at customers and go, you make the investment in this technology. We're gonna continue to develop on that. And we're gonna bring tool sets that are gonna allow you to like data governance. You know the ability to scan for ransomware and

85
00:16:05.090 --> 00:16:24.149
Ben Rogers: stores. I mean, there's a lot of goodness that our company is looking at bringing to this platform, particularly in this unified storage area. It's a big market for us, you know, and it's it's a relatively new market for us. I mean, we've been doing this a while, but we're actively starting to get aggressive with our place in the marketplace, and

86
00:16:24.270 --> 00:16:26.780
Ben Rogers: you know people like Ivc are seeing that

87
00:16:27.210 --> 00:16:36.590
Philip Sellers: well, and and I guess it's also important that this is baked in, not bolted on. You know, a lot of the competing solutions have something sitting in front of

88
00:16:36.700 --> 00:16:38.570
Philip Sellers: maybe traditional storage.

89
00:16:38.590 --> 00:16:42.929
Philip Sellers: And they're trying to serve up. You know, these modern protocols.

90
00:16:43.130 --> 00:16:51.370
Philip Sellers: This is truly baked into the platform. I mean, how important is that, Harvey? I mean, not having kind of that bolt on mentality.

91
00:16:51.790 --> 00:17:04.619
Harvey Green III: Yeah, I mean, hugely important. You know, this is something that I had been talking about overall with Newtonics in the way that they took their approaches. Not to just

92
00:17:05.020 --> 00:17:11.019
Harvey Green III: bolt on overall in their in their platform. Being able to have

93
00:17:11.140 --> 00:17:29.049
Harvey Green III: that. Ii guess I'll I'll refer to it right now. The smoothness th. The things that all work together because they were made together, and they were programmed together. You know. Not just oh, I like that. Let me pull it and then try to make it all work together.

94
00:17:30.100 --> 00:17:31.869
Harvey Green III: being able to.

95
00:17:32.060 --> 00:17:42.020
Harvey Green III: Yeah. Yeah. Being able to have something that is designed that way from the beginning makes a huge difference and especially

96
00:17:42.100 --> 00:17:48.910
Harvey Green III: when you get down to, you know, being able to administer it, or being able to to use it as a user

97
00:17:48.970 --> 00:17:57.439
Harvey Green III: having that consistency and thought process the whole way through makes a huge difference in the experience you get out of the other side.

98
00:17:58.670 --> 00:18:03.530
Jirah Cox: Yeah, having that like a one hand to one hand to shake right? That can cover.

99
00:18:03.620 --> 00:18:21.849
Jirah Cox: you know, hardware, hypervisor storage, the firmware update process and engine the maybe even your workloads right? If you wanted to choose to run like stuff like postgres on us even even manage postgres, for we can help out

100
00:18:21.930 --> 00:18:35.699
Jirah Cox: even with supporting stuff like that. And then query against the S. 3 storage set as well like, that's a pretty good single hand to shake for all that stuff like you know, who's gonna be in the trenches with you when you really need to solve a problem

101
00:18:35.820 --> 00:18:36.620
Harvey Green III: right?

102
00:18:38.410 --> 00:18:45.180
Philip Sellers: So jar I wanna pick at the querying that you brought up around Snowflake. I mean

103
00:18:45.410 --> 00:18:49.980
Philip Sellers: that to me, potentially has so many huge advantages. I mean.

104
00:18:50.080 --> 00:18:58.320
Philip Sellers: we're not talking about a database, but there's a certain amount of metadata that goes along with things stored in in

105
00:18:58.670 --> 00:19:02.540
new tanks. Objects? Can you dig into that just a little bit more

106
00:19:02.570 --> 00:19:06.429
Jirah Cox: sure, I mean spot on right. Not a database.

107
00:19:06.460 --> 00:19:27.530
Jirah Cox: but helping solve for query, answers to query like questions even faster. Right? Can have implications on data, governance, on application, performance and responsiveness. For what can I even do with it? Right? Even stuff like we've touched on splunk here right? And part of part of using spunk the right way on our platform and helping customers get

108
00:19:27.530 --> 00:19:38.519
Jirah Cox: to the right sort of economic solution. Overall, of course, involves running. You know your tier, one slog and high performance in scale out fashion.

109
00:19:38.520 --> 00:20:07.159
Jirah Cox: for the right. The right level of performance for, like, say, days, one through 30, but for days, like 31 through like 3, 65. Well, now, I also wanna have great performance. But it's all just a bunch of text, right? So if I can put the query to the platform the right way, even from like, say, spinning disk even coming from very large clusters, very diverse data sets. I can still keep that responsiveness up and get to the answer. I wanna get to very, very fast. I'm not like doing queries via like carrier pigeon.

110
00:20:07.820 --> 00:20:08.610
Philip Sellers: Yeah.

111
00:20:08.810 --> 00:20:28.990
Philip Sellers: And and and that's an interesting thing, because, you know, in my mind, I think a lot of times of object stores having images having data streams basically stored in them. But you know, with splunk, it's gonna be text. And so you you have that benefit of being able to actually decipher that pretty easily. I would assume

112
00:20:29.960 --> 00:20:51.080
Jirah Cox: totally and with objects even one of the, in my my opinion, under some features, is like stuff like fun stuff like dual presentation, where we can do like S. 3 based presentation as well as like nfs. So I can ingest say, like click stream data from like a web, form one way, but analyze it a different way and have have different ways to approach the exact same data set.

113
00:20:51.470 --> 00:20:58.680
Philip Sellers: And that's a huge benefit. When we start talking about layering on analytics platforms onto this

114
00:20:59.290 --> 00:21:12.079
Philip Sellers: throw it after the group. I mean A, as you're working with customers. Are there any really interesting use cases that you've come across that you were like, wow! That that's really invented. That's really cool.

115
00:21:13.030 --> 00:21:32.550
Jirah Cox: I mean, sure. But I can tell you about them. That's a good answer. That's a good answer. Harvey sold my answer. The no, even I mean touching back on and this one might be is is is topical even for for you guys and for the audience.

116
00:21:32.560 --> 00:21:46.820
Jirah Cox: we have a a customer who hosts a backups as a service right? Which typically, for you know, connectivity to the on-prem users. Data set would involve lots of complicated tunnels and lots of, you know, multi tenant type of complicated networking.

117
00:21:46.820 --> 00:22:14.790
Jirah Cox: the benefit of objects right as that able to be secure even over the open web technology is that it's an easy endpoint to deploy and manage. And hey, here's your key key pair for sending your backup data to us right? And then it's easy for the customer to manage easy to prove that it's secure and easy for the provider to say, yeah, we're open for business, right? Whether it's a little bit of data or a lot of data or a little bit of data that grows into a lot of data

118
00:22:15.350 --> 00:22:18.050
Jirah Cox: we're here for all of that. Right?

119
00:22:18.060 --> 00:22:26.010
Jirah Cox: so scalability, security and and accessibility of the platform, all sort of key there to that kind of use case.

120
00:22:26.090 --> 00:22:41.899
Philip Sellers: Yeah, Ben said it earlier security baked right in. So you don't have to worry about it. You mentioned that again. It's it's it's really the the beauty of the platform like this, is it it? It was made in our modern error. It wasn't something that was had to be.

121
00:22:41.940 --> 00:22:45.179
Philip Sellers: you know, refactored. It was meant for

122
00:22:45.350 --> 00:22:49.740
Philip Sellers: cloud use cases. So it's a huge, huge benefit here.

123
00:22:50.070 --> 00:22:51.150
Jirah Cox: Yeah, spot on.

124
00:22:51.420 --> 00:23:10.960
Ben Rogers: I think, another benefit of all this specifically for new customers and existing customers both is the ability to consolidate your tool set. This brings, you know, a lot of lot of our customers are running, you know, objects in another, another store or another service. It's another pane of glass, or having to manage.

125
00:23:10.960 --> 00:23:22.389
Ben Rogers: And so we've really seen some customers. One go. Wow! I can do this on your platform, and I can do it under the same prism that I've been using the whole long. Yes, you can. And then to come and

126
00:23:22.390 --> 00:23:28.720
Ben Rogers: to come back around and go. Now you can do it with performance. And we can, you know, add all these things that we you now can

127
00:23:28.720 --> 00:23:47.000
Ben Rogers: run container workloads. These AI workloads in in A in a relatively thin storage area. I mean, it's an incredible story, and it's one that we really do have a lot of customers starting to go. How could I collapse? Tool sets and product sets into this and and make this the platform?

128
00:23:48.000 --> 00:23:52.430
Philip Sellers: Yeah, I think that's a great point. Man the the

129
00:23:52.970 --> 00:24:05.379
Philip Sellers: ability to pair it with containerized applications is is really great. Because, you know, one of the factors of of those self contained applications is that your data?

130
00:24:05.430 --> 00:24:21.709
Philip Sellers: It's sort of encapsulated and lives together. And so just like we were talking about where the metadata survives around this inside of the new tanks objects. Now your containerized application can talk directly, pull those things in and make use of them

131
00:24:21.710 --> 00:24:47.189
Philip Sellers: natively without having to have some some other data store somewhere else that that it's talking to correlate things together. I'm gonna go off script here. How you made it do that with all the background, other for the crowd. We just had an interesting we're all Cameron. And we had interesting background activity going on with one of our participants. That for me.

132
00:24:47.190 --> 00:24:56.049
Ben Rogers: I've lost for a minute. So, Philip, good job keeping it straight. Well, you know, we we always

133
00:24:56.060 --> 00:25:10.500
Philip Sellers: expect the unexpected. I guess you know the it's it's the world we live in with with Zoom Meetings today. Well, guys, this this has been a great discussion. You know, unified storage is one of those

134
00:25:10.870 --> 00:25:20.910
Philip Sellers: I feel like mainstream products within the new tanks portfolio that just makes a lot of sense for so many customers. You know this this one.

135
00:25:20.960 --> 00:25:27.269
Philip Sellers: whether you're you're thinking about object store for backups or for you know,

136
00:25:27.410 --> 00:25:43.249
Philip Sellers: a imaging video files. You know, patient records. There's so many different ways that you can leverage object store. And it has become kind of that standard for storing information on the the Internet. So

137
00:25:43.270 --> 00:25:50.350
Philip Sellers: guys, II just wanna say, thanks for for the discussion. Any final remarks wrapping up

138
00:25:53.430 --> 00:26:04.579
Jirah Cox: test drive.

139
00:26:05.720 --> 00:26:33.350
Harvey Green III: Yeah. And for anybody who wants one of those really, really live wallpapers like, I have going on behind me with, you know, the kids throwing balloons up in the air, so live you can just pinch it and let me know I give. Make sure you get one promoting the goodness of the platform. I feel like

140
00:26:33.610 --> 00:26:40.840
2,024 is going to be a good year for new tanks, and we appreciate your partnership and man. We appreciate you having podcasts like this. So thank you.

141
00:26:41.010 --> 00:27:04.899
Philip Sellers: Yeah, we appreciate you guys, too. You know it. It says, a lot. When we have an active partner that we're working with, like the new Tanks folks to Gyra. Then your support is is great. We're just gonna have a love fest here at the end of this podcast I guess. But I mean that you guys are great for showing up and also giving your time to all the listeners

142
00:27:05.230 --> 00:27:21.290
Philip Sellers: and all of our our peers that that are learning from from all of the work that we're doing together. So we really appreciate you. and to those listening. Just want to say, thanks for spending a few minutes with us, too, on another XenTegra podcast

143
00:27:21.350 --> 00:27:32.180
Philip Sellers: a podcast with context, we hope that's always our goal. They're a little bit unscripted. Hopefully. You laugh a little bit, too, and learn something at the end of the day.

144
00:27:32.350 --> 00:27:38.650
Philip Sellers: So until next time. Thanks, gents, and thanks. Listeners, we will. We will see you in the next episode.

145
00:27:40.940 --> 00:27:41.929
Thank you. Guys.

146
00:27:42.360 --> 00:27:43.490
Ben Rogers: Sorry everyone.