Transcript
of just kind of leading us through a discussion today with George Crump, our chief marketing officer, longtime industry analyst. And you know what, George, what even is this, granularly, the flash and memory super cycle Do you want to even just help us get a sense of what are we talking about here, what is this in fact? Yeah, it's a very real phenomenon, I guess, I don't know if you would even call it a phenomenon, it's a reality. You know, we entered 2026 thinking this was going to be the year that we had a big challenge, you know, we being IT, had a big challenge in front of us in regards to VMware and deciding if you're going to exit, and if you are going to exit, who you're going to exit to, we of course, were hoping it would be us, or are hoping it's us. And then, really, toward the end of last year, and especially now, we are seeing a, the first immediate impact was a pretty massive increase in RAM, which then, and really was memory in general, and the substrates within memory, which immediately then led to a pretty large increase in flash, which now has had a ripple effect, which, frankly, might be the big, well, it actually is that a ripple effect, I was talking to my friends of mine that are in the what we would call the hard drive space, and they're running out of supply. And so I was just kidding our CTO, Greg, who's been on the webinar lately, saying, hey, we got to figure out how to write to punch cards, man. Because that's, that's about where we're heading. And then, but, you know, so we started to run into supply issues with servers, we're starting to see even, not that it would apply to us, but even laptops are becoming more expensive, and eventually, probably harder to get. So it's just a ripple effect throughout the whole industry, and we'll talk about sort of the sources of all that here in just a second. So is it fair to say, it's not just a VMware story any longer, and it's not only a hardware story, but maybe kind of both happening at the same time? Yes, absolutely. And I think it's what you're looking for is, can I exit VMware to something that can also help with the other problem? Because frankly, if you can't fix the other problem, all of a sudden VMware doesn't, you know, in perspective, kind of doesn't look like its prices went up that much, right? I mean, okay, its prices are going up three to four X, but if your server prices are going up five, six, seven X, you know, it just, it becomes a very odd situation that we're in right now, but nothing that I've seen before. Okay, yes, it is a perfect storm, I think is the way that I've begun to think of it. So what are these? I think the obvious low hanging fruit is, of course, the VMware price increases. That's almost old news now. It's still real, budget still may not have been keeping pace with that alone, but it isn't that alone any longer. So what are these market realities that we're really talking about here? What can you tell us about them? Yeah, you know, on the VMware front, it's becoming more real, I think, to more and more people, because 2026 and 2027 happens to be a year that a lot of people's licensing comes up for renewal, and they're going to see a shock, right? But if you look at, you know, if you kind of go to the bottom right of that slide, we're seeing about 171% increase year over year, we expect that to run at least through 2027. My personal opinion is, I think it's going to go much longer than that, you know, and then those same prices went up just in this quarter have gone up 50 to 60% or greater. And so memory is really becoming a problem. And then, like I said, it's the whole componentry that makes memory. So anything that has to do with memory is impacted, right? So flash storage, storage systems, servers, laptops, RAID controller cards, anything that needs memory is going to be impacted by this. And then if you look at the other drivers, so where did this come from, I think is kind of the question. And it really all started with the AI, what I call AI factories, big AI data centers and their demand. From what we understand, and I think it's pretty common fact now, but OpenAI essentially bought all inventory from all competitors or most of the inventory from competitors to each other and dried up the market. Well, the other AI guys, of course, they need memory too. And so they're willing to pay anything and they can kind of do it because at least right now in the AI industry, profitability is an option, right? So and then you also had just normal baseline growth in business, both enterprise data centers, medium to small data centers and public cloud service providers. All of that was growing. And so none of that was going. And then I think the bigger long term element, somebody asked me the other day in an interview what I thought would cause this to stop. And, you know, the conventional wisdom is five years because that's about how long it takes to bring a fab online. And that's true if we all said, OK, let's go build about 10 fabs right now. I haven't seen anybody do that. So that's a problem. And then, you know, you've got all kinds of stuff. Like if you started today, you wouldn't probably break ground, I would think, at least a year or two, right? Because you've got all kinds of regulations and things like that. I think the bigger challenge, what will ironically slow this down, is power. We're not going to have enough power to drive all this stuff. Right. And so there's a massive problem. There's a pretty interesting story if you ever want to kind of Google it or whatever you do with it nowadays. But the, shoot, I'm drawing a blank on the Grok factory that they built in Memphis. It was supposed to all be powered by the river that runs by there. And that river happens to apparently power a lot of that region. Well, they were going to, their power requirements were so big, they literally were going to take all the power that the river could generate. And so this very, what was going to be a very green data center now is surrounded by diesel turbines. Oh, wow. I have a friend of mine who works for, I think it's Caterpillar, and he sells turbines. They are sold out until 2030. Right. I mean, it's a real problem. Now, we can get all kinds of philosophical debates, and if you guys want to, I'm happy to, as to why this is happening. But the reality is you've got a data center to at least maintain, if not build. And hopefully today we'll give you some ideas how to do that. I think the slide almost speaks for itself, but I'd love to hear your explanation about what we're really talking about with regards to density, new risk profile. What is the bottom line here in the current market, which to your point and other experts, is not going away anytime soon. Right. So what you've got to do, in my opinion, is number one, so you've got this VMware thing, and let's use this as an advantage. So as you pivot, let's pivot to a platform that requires less memory, right? We no longer live in a world where you can be inefficient because memory is cheap, storage is cheap, all these things are cheap. We now live in a world, and I think this is going to continue for a reasonable period of time, where efficiency really matters more so than it ever has. And so look for a platform that from a starting point, right, if you're starting, like there's some, for example, hyper-converged solutions, who from a starting point, if you're using their storage software, can require 32 gigs of RAM before you start your first VM, right? And so you've got to factor that stuff in. And so look for a sort of a unified code base that can really trim that down. We'll dive into all this stuff in some detail. The second thing is, you got to be able to run on what you got. Number one, and it's not just if you bought new servers, it's going to cost you more money, right? It is literally, you might not be able to get another server, right? Right. And so being able to run on what you got becomes very critical. Also, by the way, and I can't remember if we talked about it in this particular talk, but I think being able to run on reconditioned stuff is going to start to look really attractive. And so we'll weave that into the conversation as well. And then at the same time, reduce future needs. Look for a platform that can pack VMs in tighter, so you can shrink server counts and bypass supply chain things, right? The closest thing we've come to this was in coming out of COVID. I'm sure everybody remembers all the logistical issues we had. That was pretty short lived, right? This, I think personally, I think this lasts at least till 2030. The really negative side of me thinks we might never get out of this thing unless we literally run out of power and then that'll slow it down. Wow. You heard it first here, folks. So a couple of quick things, George, thank you for walking us through this. Do we want to talk later about the, not just the less overhead, but even the techniques of the way memory is utilized in various platforms? That may be something we want to talk about in the coming slides over the next little while. Yeah, actually on the next slide, we kind of tied into it. Okay, awesome. So, you know what I wanted also just to mention, so most of you here probably check in periodically, maybe you spend a lot of time on Reddit. I just read something, just to amplify what George is saying, I just read something from, poor guy, I have no idea who he is, but I really feel for him. I think he is in the UK though, who was just venting to his colleagues about a project that had been long planned and all of a sudden, all the prices have gone up 150,000 pounds total and months of delays have been introduced and he's not frankly sure if the project will ever even happen at this point. So this is not hypothetical that we're talking about, this is happening maybe to some of you, I hope not, and certainly to your peers and your colleagues already. This is not something that's coming, although I suspect it will get worse to George's point as well. So I just wanted to kind of throw that in there just so you've probably seen what I've seen as well. All right, so let's move on. So, all right, so let's talk about how, you know, more efficient platform, sure, what are some of the ways that we're really describing here, George, that are practical, that can actually be addressed now versus somewhere down the line after crises have already struck? Yeah, I kind of let the cat out of the bag on this one a little bit, but if you look at the way the typical hyper converge, again, in a world where memory is cheap, storage is cheap, processing is cheap, and all of that's readily available, you're going to act differently, and you're going to do things that get you to market the fastest, right? And so the fastest way to get to market if you're developing a hyper converge architecture is to have five or six different teams working on different sections of code, and in some cases, totally different applications, and then kind of bring those all together with like a vCenter or something like that, right? So nothing wrong, I understand why a company would decide to do it that way. The problem is, again, at least for the next, in my opinion, five years, we're not living in that world anymore. And so now, every little layer takes memory, right? It also hurts efficiency and all that kind of stuff, and we've shown performance data where we took a different approach. We're much slower to market, and we wrote all the code as a single code base. And so that gets rid of a lot of redundancies in the code. And so, for example, our code is about 400,000 lines, a little less than 400,000 lines, the combined stack that you see on the left is probably 25 to 30 million lines of code, right? So let's assume for a second, we have to always prove this to you, but let's assume for a second we're delivering at least feature parity, then if I can do that in massively less code, you're talking about a much more efficient platform, right? And the starting point, at least as it relates to this, is how much memory you need to get started, right? And so in our world, the starting level of memory that you need is significantly less than what you would need in other architectures. Maybe we bring up a little bit of this as well. Even before Flash and memory were in crisis mode with regards to their cost and even their availability, I remember regularly, George, hearing from customers when we're just talking about math, right, the code and the content of the efficiencies built into our platform versus the stacks that other people are accustomed to using, I remember hearing 20 to 30% increases in performance pretty regularly, almost casually, that the math matters. Absolutely. A hundred percent. Yeah. So you might be thinking, okay, what does a deduplication slide do in a presentation about saving RAM? Fair question. So it has much to do with this efficient code base and really at the heart of our code is, or at least one of the key ventricles of our code, is deduplication. And it runs throughout the product. And so next couple of slides, it'll tie in even more, but I didn't want to say, hey, we do this without explaining what this was. So the way our dedupe works, very similar to, in many ways to dedupes that you would see on a storage array or, well, I guess that's where you would see it, or a backup appliance. But because it's integrated at the OS level, you know, and in that OS is also the hypervisor, the networking, the storage, everything's in there. Everything benefits as a result of that. Because now we only see data once, because this happens right on the front end. And so at a minimum, most of our, I mean, the overwhelming majority of our customers will see two to one gains. Most customers see three to four to one gains in efficiency as a result of doing this. And then it also has other benefits that we'll probably talk about a couple of times here, but as we move to Drive, so one of the things we'll start talking about with how having people throw sharp objects at us now is using consumer grade drives or using refurbished drives. I was doing some research for a calculator that we're working on, and the cost of a used flash drive is massively less expensive than a new one, right? I mean, like significantly, because flash has this kind of bad reputation about wearing out. So if you can do things, A, to protect in case it does wear out, and then B, slow the rate at which it continues to wear, those are good things. And so the way this flash works, because it's at the front, the only thing that hits that flash drive is perfectly, is, you know, totally unique data, right? And so there's less data being written. Also, the way our algorithm works, it's much more intelligent in how it writes to flash. So there's, each flash is a, you can think of it as kind of like a bucket or a cell is probably the right term. The more of that cell you fill up before you go to the next cell, the less cells you're going to use, right? Well, the way our product works, we fill up more of the cell before we move to the next cell. And so, number one, we reduce the write traffic. Number two, we spread that write traffic out perfectly across all the drives in the system. And then number three, we fill up more of the cell, if you will, before we have to do that. And so as an example, I think I might have said this on a prior webinar, but we have a customer that I spoke to a few months ago that's been running our product for, I don't know, five, six years now on consumer grade flash. And if I remember right, it's a four or six node host environment. The writes across that environment are perfectly set at 33 percent. It doesn't matter about 33, that just happens to be where they are. But so think about that. They got five year old drives and their wear level or their wearing is at 33 percent. So they still got another, you know, 67 percent left in those drives. Right. And so and that's that's a benefit of a combination of really these three things. We're only writing unique data. We're controlling the I.O. scheduling, which means we're filling up more of the cell. And as a result of that, and then we're spreading it out perfectly so we don't burn out a drive. And so that helps with all of those aspects. We're talking about flash in memory, supercycle shortages, expense, wait times. And what we're saying here is you could use the more expensive, but you can also use the less expensive commodity or even refurbished. So just more ways that we can enable you to save because we then are able to help you get the most use imaginable out of these drives. And we didn't just create this type of technology for a supercycle. This is just how we operate. It just so happens to be extremely beneficial when flash is now through the roof, if even available. So did I get that more or less? Absolutely. Yeah. And also, as we go through more of this presentation, you're going to keep hearing about global inline dedupe. And so it's important just to know how that works. It's in the OS. It's available all the time to all nodes. Everything understands it. And so it's highly optimized, not only per drive, but just within the environment itself. Got it. So now we're going to talk about RAM caching as it's affected by this global inline deduplication. So with that, George, looking forward to hearing more about this. Yeah. And so the first thing I want to clarify, because the term, you'll hear us use a term, globally deduplicated cache, and it's accurate, but I can understand where it could be confusing. So we are not doing deduplication on the memory, right? But we are caching data that has been previously deduplicated. So the only thing that's going into cache is unique data, right? And so if there's a block of data in cache, let's say an important core component of an operating system, let's say Windows, and then you're going to boot, I don't know, 50 Windows servers, there's a good chance the exact block that all of those servers need is already cached, right? And so that's basically what we mean. Now, why does this matter? Because as a result of this, we are able to reduce the amount of in VM memory. You literally need no in VM caching, which you would tend to do, like, say, for a database VM or something like that, because what do you need a cache for? Because a cache is faster than storage, right? Well, our faster-than-storage cache is available to all the VMs all the time, and it's globally deduplicated, right? And so one of the things that customers will be able to do as they start to right-size their VMs is dramatically shrink the amount of memory that the VM is using, right? And so we have test for testimonials where they'll see a 25 to 50% reduction in per VM memory allocation, and a big initial cut of that percentage is because of this globally deduplicated cache. Plus, by the way, VMs that you wouldn't necessarily think to do a lot of caching and probably will definitely benefit because another VM has put data and, you know, has asked us essentially to put data in cache, right? And so it's universally available and everybody universally benefits. And it is interesting. It makes it odd when you do certain benchmarks with us, right? So if a customer does a VDI bootstorm is one of the things a lot of people test. Well, guess what? That test goes really well because everything's in cache. So, you know, it's that sort of stuff that is kind of interesting. But this does, this is one of the first, so I kind of look at this in phases. The first thing is from an OS level, if you will, we just need less memory per post. Then per VM, you could scale down the amount of memory you assign to that VM because of this global cache. OK, and so those are sort of the first two phases of saving memory. And those two steps in and of themselves tend to save a lot of memory for most of our customers. Awesome, well, thanks for taking us through this, George. And, you know, something just struck me, George, that you said it a few minutes ago and it kind of went right over my head, or at least I thought it did. But it apparently did get caught somewhere in my thought goalie, got a hold of it. And that was just because I think it was really super important. And that is that pretty much everyone else on the market, you're consuming expensive, hard to come by memory just to run the platform. And we're talking about, before any VMs, and we're talking about something very different here. So I'm looking forward to, I think we probably talk a little bit more about that at a system level. But I think that's really, really important differentiation that I'm pretty excited about. So commodity NVMe, even possibly refurbished, you were talking about earlier. How is that safe? How are people able to go home for the evening or go home for the weekend and feel like, all right, things are going to be OK? I think we have some good answers for that. Yeah, and so it's interesting because, as I said, I'm building this other tool for the website. And as part of that, I'm trying to be accurate in my research and things like that. And so the price difference between commodity NVMe and enterprise NVMe is not insubstantial. If the drive costs $1,500 for an enterprise version, it might be as little as $1,000 for a commodity version. Over 10, 20 drives, that could really add up, right? Now, what do you give up? Well, you give up, primarily you give up what I would call data protection. You know, most enterprise drives have a capacitor, so because most drives will have kind of like a buffer and they'll manage the write internally to the drive. We don't count on that buffer. Again, Greg and his team, I always jokingly say they have a high distrust of hardware. I don't know what hardware did to them in a past life, but they don't trust it at all. And so they build their own protection into the data path. And so we manage the write to it. We handle all the I.O. scheduling, all of that kind of stuff, right? So, you know, we know when it hits the drive, it has hit the drive. It is on permanent media, right? That's a big win for us in this use case. And we do that without loss in performance, by the way. Again, our Frank Global inline deduplication comes up. It's, you know, there's less writes going to these drives because we're, you know, netting, you know, somewhere between 300 and maybe 400% of them out. And the final part, and we'll dive into this in more detail on another slide, is I.O. Guardian, which is a, it's a server that runs Verge OS. It does not, it is not intended necessarily to run another virtual machine. But what it does do is it collects essentially what I would call the third copy of data. And so you size your I.O. Guardian server as large as you do any other server in the environment, I'm sorry, your total capacity and all that capacity hits here. Then if there's a, your concern is not a single failure because we're protecting that. But if you, let's say you lost three drives across three servers at the same time or within, you know, 10 minutes of each other. Well, we can, because of I.O. Guardian, I can still service data in real time to the VMs. And we'll dive a little bit deeper into I.O. Guardian as we go through. But it's these three things that make commodity drives or refurbished drives much more palatable. And, you know, if you hear those two terms, especially refurbished, you might have an immediate visceral reaction against the idea. You might not have a choice. I mean, I hate to say it, but you just might not have a choice for the next three or four years. You're just going to have to get whatever you can and use it. And so, you know, you're talking about the person on Reddit. Well, you know, if it meant not doing a project or doing the project with refurbished drives, well, all of a sudden that gets really interesting, doesn't it? Right. And so that's kind of where we are. And we might, I believe, and I hate to be a predictor of doom, but in my defense, I was absolutely right on what Broadcom was going to do to VMware. I think we're heading toward a very similar situation here, right, that you're going to be scrambling to get even refurbished drives. Wow. All right. Well, you may be right, George, yet again. Let's talk about one of the other, you used the word visceral. I appreciated that. I think this may be, this slide, we want to talk about perhaps a knee-jerk reaction, right? Something else, maybe less logic and more, well, we've got to do something. I do believe that I've heard from folks, I'm pretty confident you have as well, that one of the things they're considering, hopefully not doing, but considering is trading resilience, right, to enable them to kind of keep moving forward with what's either available to them, et cetera, et cetera. Maybe could you talk about this a little bit, George? I think you've heard more from more folks about it than I have. Yeah. And, you know, this goes back to the, you know, eight months ago, we lived in a world where RAM was cheap, flash was cheap. You know, we bought all flash arrays because they weren't that much more expensive than a hard drive based array, right? Funny how six months can really change your opinion on things, right? And so if you look at the, kind of the one, it's kind of crooked, I guess, but the one at the top and the one at the bottom, the RAID 6 and double, triple mirroring, you know, those would be what I would call nowadays, in my opinion, best practices, right? And both exist in case two things go bad at once, right? With a single mirror or with RAID 5, which is over more to the left there, you're obviously protected if one thing breaks. With the other two, you're protected if two things break. Right. With none of them, are you protected if three things break? And so we're hoping that three things don't break. Right. If we're going to live in a world where you're going to have, you're going to be using reverberant drives, you're going to be using consumer grade drives, you might be a little bit more nervous, right? And so downgrading your protection and also downgrading the quality of the drive is scary, right? So that's kind of the thing. Now, just straight off the bat, we, by the way, you know, spoiler alert, we do double slash triple mirroring, right? And so we have the ability to, we, as a default, we do a synchronous mirror across multiple nodes or hosts in the environment. And then you can also do a triple mirror if you want to. Now, if you do the math on that, so the only thing we're mirroring is net new unique data. So most customers, certainly with the double mirror, but even with a triple mirror, we'll end up with a net gain in capacity because if we're costing two to three X for the mirror, but I'm giving you a four X to five X because of de-duplication, you know, you're a winner at that point, right? So now with this is really what I call the architectural target, right, is, because if you're going to tell me, okay, there's a chance that two drives will fail, I'm really worried about that. So I want to spend some extra money on RAID six or double, triple, or triple mirroring and believe me, as paranoid as I am, I'm with you, we could start a club. And the only people that distrust hardware more than me is our development team, I would say. So this again, goes back to IoGuardian, right, the way IoGuardian works is it updates the IoGuardian server on your snapshot schedule, okay, so that also means you can set different resilient levels, if you will, by workload. And then you can also, so what happens is this is a, like, again, it's essentially a third copy of data, you're all, this could be a very basic server with a lot of capacity, it could, it could be hard drive base, if you so choose, and so the, and then what happens is, if there's a failure, beyond whatever your protection scheme is, so in our world, if you're running two X, or a mirror, if you lose a second drive, instead of failing, it'll go tap the IoGuardian server, and in real time, it'll pull blocks of data across the environment, and you can do that, and so instead of restoring, you know, even on a small SSD, right, four terabytes of data, it's just serving up 64k blocks of data, and only the 64k blocks of data that are needed at that moment in time, so it can do this very well. Now, if your IoGuardian server is full of flash, I think in most cases, you won't even see a performance difference, right, if it's hard drive base, you probably will, but as I always tell people, hard drives might be slow, but being down is even slower, right, and so just kind of factor that into the equation. Now, if, again, if you're part of the paranoid members of America, I gotta come up with a better name for that, Aaron, but the, if you're in that club, then the ultimate level of protection is three X plus an IoGuardian, right, where you can now, you can survive two failures with no latency loss, and four, five, six, seven failures with a latency loss, right, and that's the other aspect, actually, of IoGuardian. I should mention on the IoGuardian, it goes from, so we would call a mirror an N plus one, we would call a triple mirror an N plus two, I refer to IoGuardian as an N plus X, right, as long as the IoGuardian server's alive, and one node or host in your Verge IO environment, you're up, okay, and so that's, we literally, and I've told the story before, but we've had customers where they lost two thirds of their servers for, usually, it's human mistakes, and they were still serving data to the VMs that their customers were using, so that's the idea there. Got it, got it, it's, so this really speaks to the architecting portion of the title of our discussion today, architecting for flash and memory supercycle, this is a way to get you exponentially, I would, I feel like it's an order of magnitude greater protection for a much more average price, even with elevated pricing, and George, what about, is there an element of this that also then speaks to or helps with rebuilds, in other words, it's keeping data served, it's keeping things running, your customers, your whatever, your users are not experiencing anything noticeable, you've got time to replace your drives or your servers, what about after that, does this have some effect on the aftermath? Well, you've set up my next slide perfectly, so let's go to the next slide, so there's our friend again, global inline dedupe, and so when a write operation comes in, it runs through that, you can think of that as a filter, and then only unique data gets written to the drives, right, and so that's what's happening, I'm showing a 3x there, but whether it's a mirror or a triple mirror, so, but why do we do this, right, so first, it's not CPU heavy, right, we're preserving CPU, I'm not running some complicated algorithm like Reed Solomon or any other parity based calculation, and so it's lighter, and guess what, consumes less RAM, it's lighter on the hosts, number two, there's no performance penalty for writes, right, in RAID 6, especially an erasure code, a higher end erasure coding, there's absolutely write performance penalties, more importantly, is when things break, right, and remember, we're now architecting for potentially older stuff, potentially servers that you're running for a longer period of time, and we got to assume that if we didn't trust brand new hardware, we absolutely shouldn't trust old hardware that somebody else might have used, what we want to make sure is if it fails, A, you can still get the data, and I think we've covered that pretty well, we didn't probably talk about server failure, HA is built into our product, VMs will automatically move where they need to move, and you're back up and running, so it's no issue there, but during that failed state, while we're either serving data from the IO Guardian server, or if you haven't exceeded your N plus, we're feeding data from the surviving copy, and it's full speed, right, so I don't have to do a parity calculation to figure out what the data is or anything like that, if you did run the triple mirror, then you actually still have two things that we could read data from, if everything, by the way, if everything's working, whether it's a double or triple mirror, I have multiple things that I can make reads from, so again, my read performance is very effective, and again, like I said, global deduplication always works its way in, but if you look at the math, in most cases, you come out ahead, because we'll get a, and I've got multiple examples, and I've got multiple customers quotes where they've said, hey, yeah, we don't know why, but we're getting much better effective deduplication than we used to with our other product, right, so very powerful from that perspective also. And just to maybe wrap up the part about the IO Guardian, and I love that we can confidently and accurately talk about RF3 plus protection, but in this, especially this environment at such a low cost footprint, I think it's just a wonderful, unexpected benefit of the way that the solution has been designed. Yeah, it's funny, when you're putting together a presentation, you just put it together, you don't think about it. So for those who haven't yet, not yet figured it out, I, you know, Sarah might have put a polling question on this, as far as what do you think George's favorite feature is, if you go with IO Guardian, there's probably a pretty good chance you're right. And again, because I am now the founding member of the paranoid people of America, the PPA actually is what we like to go by, but the, so why I'm drilling into this, right, it first of all, it's built into the software, it costs you a server and a server license, you can use really inexpensive drives, you can use a really inexpensive server, it leverages our snapshots, and so it's updated as quickly as you take a snapshot. Generally speaking, what we see is, if it hasn't been captured by the snapshot, guess what, it's still in that cache that is benefiting from global inline deduplication, right? Restoration is inline, so this is not even an instant recovery that some of our friends like Veeam do, which, again, we have a lot of respect for, this is just given data back, right? It's there, it's ready to go. The rebuild is offline, right? And so when you replace said failed drive or drives, we pull the data from the IO Guardian server, not from production servers. So again, a little help in performance while the rebuild is happening. And as I mentioned, it's near continuous protection, right? So it works really well. But I think we've kind of, if they don't know what IO Guardian is now, I've really failed in my mission here. Well, I appreciate the, you know, and it is a big difference. And so I appreciate that we spend a little bit extra time talking about it, because this is not something that you can just shop around for. This is something really unique to what we do here. And by the way, for those of you that are newer to Verge, or maybe new, maybe this is the first time you've come in and heard us discuss anything that we do. And again, new or not, we appreciate you being here. A lot of what we do, a lot of the places that we get you to that you need to be, we do it in a different fashion. So even something comes to mind when we just casually talk here about snapshots. They're not traditional snapshots. They're very different. I bring this up because if you're newer to us, I think we either have or we will have a link that we'll put in the chat. We'd love for you to, you know, just when you have a chance, click on it, find some time and it's convenient for you. And then let's talk. I would love to kind of take you through the whole solution in a little more detail. And how we do many of the things that we do differently and advantageously for you. We are covering quite a few of them at a very high level here, but there's more. So please feel free to schedule some time with me if you'd like to discuss further. We'd love to talk to you. I would love to talk to you. And speaking about some things that we do very differently, George, this whole idea of servers and server deployments and can I get new servers? Can I not get new servers? What kind of memory are we talking about? What kind of price increases are we talking about? Can you talk us through that a little bit here? Yes, absolutely. So I kind of tripped everybody by saying, if you had a polling question and you picked IO Guardian, it actually would take a very, very close second. This is actually, to me, the most important part, because if the doom and gloom version of all this happens to be true, which you could probably tell that's where I'm siding, you might not be able to get it right. A lot of, we're seeing, not a lot actually, a few of the storage guys now start to suddenly promote auto-tiering again and going from flash to hard disk drives, which is fine. What if you can't get them? That's not going to do you any good. And so this, I think, becomes, if it gets ugly, this becomes very critical for a lot of reasons. But the other thing we did in addition to this unified, very efficient code base with an amazing global inline deduplication capability is abstraction. So we've abstracted ourselves from the hardware. Again, it goes back to our distrust of hardware. And we can run, I'm hesitant to say anything, but let's just say virtually anything can run, can be a server for us. So my, I'm traveling today, but my home lab is two mini PCs, right? And they perform actually really, really well. The lab that I'll show you here in a second, I'm actually going to show you our lab at its highest level. And it's running on a collection of servers that are somewhere between four to eight years old. Okay. So it gives you an idea. We can mix and match all these different things. And that becomes critical, right? Because again, if you can't get it, or, you know, you're talking to your vendor tomorrow and say, hey, I want to order six whatevers. And they say, great, it'll be there in six or seven months. That's a problem, right? And so the ability to not only reuse that hardware, but get more out of that hardware, which is another thing we'll talk about here in a second. I think it's super critical to the conversation and it's a core aspect of our product. Absolutely understood. All right. So no forklift, hardware forklift required. What in the world does that mean? What are we talking about here, George? Well, so if I can reuse your existing hardware, or you can't get hardware, right, that one of the key things is I have to be able to do what we call an in-place upgrade, right? And so the way that works, you know, I've got VMware as an example. I don't know why I would have done that. But so let's say you got a VMware environment. What you need to do is move all your VMs off of one of the servers. Re-image that server as a VergeOS server. That's kind of being represented there in step two, right? And then what you do is move a group of your VMs back over to, in step three, you move a group of the servers, sorry, VMs over to the VergeOS environment, freeing up one of the other machines. And you just keep doing, switching between, you know, basically step three is a repeat and rinse sort of thing. And then you end up with a complete process. So to give you two examples of this, I selected Topgolf, who we did a webinar with back in August, and then Olensko, who we did a webinar with in January. So Topgolf, at each venue, they had a six-node environment, and they've shrunk all that to three, okay? They do these conversions in the morning before the venue opens, and they're done before the venue opens, okay? So a complete movement there, very, very fast. They love it, you know, and they've retired all these servers. They might be a good source for servers. I don't know if that's true. And then Olensko, same thing. They did a in-the-middle-of-the-day migration, no downtime, no users new. They use all their existing hardware. They got a third-party maintenance contract on it to save money further, and it's going great. So just two real-world proof points of this actually working. All right, so talking about retired servers, excess hardware, what could you do with it? Yeah, this is more or less the last slide here. So here's what we see people doing, and obviously we support both of them. The one is, hey, let one of them become that IO Guardian server, right? Give you an extra layer of protection, throw some capacity in it, you're off to the races. The other one's kind of a new term for us. We didn't really talk about this much, but we now call them part donors, kind of like the IT equivalent of an organ donor. You retire a server, and in most cases, right, you've got a group of servers. We mix and match servers, but we tend to see is a customer will have four of server X from vendor Y and then four of server A from vendor B, right? Well, those parts, generally speaking, are interchangeable. You can collapse that and add more memory to an existing server or more capacity to an existing server. One of the reasons you would do that is because of the way we license. We license by the physical server, so we don't care how much memory it has. We don't care how much capacity it has. We don't care how many cores it has or processors or anything. So that's what the idea here is. Your extra servers can either become part donors or, like I said, they can become a dedicated IO Guardian server. But with us, to take advantage of the licensing, you want to build big, bad servers or big, nice servers. There you go. So, all right, George, thank you for explaining that. And really, just to leave everyone with this concept of what we've introduced here to the market and the new value that it brings in this flash and memory super cycle is this, let's call it the server extension bridge. The bottom line is we are not just, Verge IOs, Verge OS is not just a virtualization alternative. It is, of course, but it's really this macroeconomic strategy that allows you to bypass this super cycle in some very palatable, even better than palatable, advantageous ways. So, if you could use a server extension bridge, if you are looking for an escape hatch from VMware, as so many of your peers are, whatever your reasoning is, please reach out. Love to talk with you. Really appreciate you joining us today. Thank you.
