 Hi everybody, this is Dave Vellante at Wikibon.org, and we're here in the Marlboro headquarters. And we're talking continuous availability and data at a distance. It's an important topic. I mean, we've all seen the recent disasters, the Hurricane Sandy, we had a big snowstorm here last week in New England, and it's top of mind for people with businesses going 24-7 and commerce happening more and more online. It becomes increasingly important for organizations to think about how they architect and how they construct systems that essentially don't ever go down. And we're here with Matt Allen, to my right is Matt Allen, who's the Senior Director of Security and Risk Management at EMC Global Services, and to his right is Matt Waxman. We've got the Matt show today, who's the Senior Director of V-Plex Product Management. Matt and Matt, welcome. One Matt is two Ts, one is one T, inside joke, but you get it. Thanks very much, guys, for coming on to theCUBE. Thanks for having us, Dave. So we have this topic, and it's an evolving one. We've always talked about high availability, even continuous availability. After 9-11, I know EMC played a big role with SRDF and a number of your clients being able to recover and keeping the financial system, but we're now 10, 12 years on, and there's a lot more data, a lot more pressure, a lot more risks to business, and you guys have made an announcement, I guess yesterday in this regard. So why don't you guys take us through the announcement, and then we can get into the discussion. Sure. So the announcement is the formal announcement of us rolling out a service offering that's designed to help our customers better understand not just what their infrastructure requirements are to achieve something referring to as continuous availability, but what it would take from a roadmap perspective to achieve it over an extended horizon, what the cost and benefit, the kind of elements of that investment decision would be. So for context, continuous availability is a service level that's created by infrastructure application architectures that have no single point of failure, okay? So at some level, the component, the application, or site levels are always up, always moving, always operating. Okay, so the announcement is specifically a services offering, and so it's an assessment service, saying also included in that is a business case outcome, is that right? That's correct. So yeah, tell us what the client gets. Sure, a couple of different offers. One is a current state assessment to get a view of what their needs are from both an application and an infrastructure readiness perspective, a roadmap that gives them some sense of what it will take to achieve continuous availability or a continuous availability architecture, an active, active architecture, which Matt will talk about a little bit in just a second. We're also going to help them better understand what the operational requirements are from a continuous availability perspective. One of the things we'll cover today as we talk about this is the fundamental changes of operational requirements that most of our clients, most of our customers are having to engage in when investing in this journey. It's not simply a fundamental different view of backup or disaster recovery or business continuity. It's a fundamental economic shift in the way they run their businesses. And so from a transformational perspective, there are a series of different requirements. It's not just technical anymore that they've got to consider. Our services are designed to help them with that. Okay, so I got a number of questions in that regard, but Matt Waxman, I want to go to you for a minute. You're a product guy, but what are you seeing in your product is obviously a fundamental component of this offering. What are you seeing as the drivers of this continuous availability movement? Yeah, so it's a great question. The shift is really happening around people looking at automation. Really, when you look at the transition to the cloud, the core component of that is automation and simplification. And when you look at traditional models of managing two data centers in an active, passive manner, it relies heavily on scripting and tooling and people, right? There's a significant OPEX that's involved with that. What we've seen is that this shift to continuous availability really moves that to a fully automatic model. Literally, no scripting, no human intervention, it's things just continue operating in your second data center. So that's really what's underlying this transition, I think, is people re-looking at the models, the admin cost, the asset utilization. We can talk about all those things, the great benefits of doing this. But it's really the shift to a completely automatic infrastructure. So in reading your press release, one of the things that strikes me is some of your messaging was around bringing together production systems, high availability, and disaster recovery. Sort of a consolidated view of those three. Am I interpreting that correctly? Is that sort of the thrust here? I think it's, yeah, it's a fair conclusion to draw. I think hopefully what we've articulated is that there's been a journey that all of our clients, everyone in the marketplace has been on, from sort of disaster recovery on the left hand of the spectrum to more advanced applications. Exactly the way Matt framed it up, that is a more advanced version of what continuous availability or an active, active environment needs to be. There's an important distinction here, though. The difference as it relates to what we've traditionally viewed DR to be is a lot of redundancy, a lot of complexity. Matt sort of touched on it. But the reality is it's not just extra pieces of technology, extra pieces of product, but rather extra effort from a people, process, and technology perspective. With continuous availability, that is eliminated in most instances. So we're talking about a material change in cost model. And the mental model too, because I mean, I would observe that typically, except for the obvious applications, things like disaster recovery, oftentimes, even backup sometimes is a bolt on. It's like, oh, hey, we deployed this application and we got to protect it. And so what do we do? And maybe we'll replicate it and maybe we'll do a good job. Maybe we won't. We do some scripting. Can we talk about the options that customers have today? Sort of paint a picture of where we are today and where you guys want to take us. Sure, so I think it's really best to think about it as a spectrum, right? Like Matt said, on the left side you can think of DR, right? And then you have high availability, which is another layer in between, and then continuous availability all the way at the other end of the spectrum. We see customers needing a mix of all those things. It isn't to say that continuous availability is the answer for everyone, but it's a model that is transformative, right? It is a different model than DR. What we see also is the opportunity to actually blend the models. So what we've done over the past year or so with the V-Plex product is we've actually integrated it together with our recovery point offering as well. And what that's given us is the ability to combine both a continuous availability story together with a DR story. We see a lot of customers wanting to do that where they have regional requirements for continuous availability and outer region for DR. So it's really the best of both worlds. So I think of things like DR and imagining like a three-site data center. And I'm going, ah, I can't afford that. Or it's too complicated and my people would never be able to manage that or they'd shoot me if I tried to put that in and my CFO would kill me. So that's kind of the one end of the spectrum. And also in looking at press release, I inferred that sort of RPO and RTO, you're trying to move beyond those concepts. But it used to start with the notion of RPO and RTO. If I wanted as near zero data loss as possible and super fast recovery times, I might go to that three-site, but a very small percentage of the people can actually afford to do that. So are you now opening capabilities up to the masses? Or does this essentially replace that methodology? Talk about that a little bit. I think there's a couple of ways to look at it. But I think first and foremost in our release, and I hope that everybody understands that we all view a continuous availability architecture, an active act of architecture as a journey to get there, to Matt's point. There are several different types of configurations that different clients will have to engage in for whatever period of time because of the different or unique requirements of their infrastructures. The compelling difference now, the reason this is such an important story now is for the first time, and since we've really gone down this scale journey around disaster recovery, we have off-the-shelf technology to answer the solution. So here to fore this has been a wildly expensive alternative, in fact prohibitively expensive, in the context of cost of uptime or cost of preventing a failure. So achieving some level of five nines of uptime, that sort of thing, has been cost prohibitive largely because we just didn't have off-the-shelf technology that gave our customers or the broader marketplace an immediate answer to the need for an active, active environment. With V-Plex, we get that off-the-shelf technology at an effective price point in a way that the economics can be fundamentally changed. And that you'll see accelerate rapidly in the near term. So I want to talk a little bit about distance because distance has often required trade-offs, right? If I'm synchronous, great. I get the performance and the low latency, but I'm subjected to a fire or a building blowing up or a terrorist act. So I go to an asynchronous distance, and then it becomes problematic because I'm increasing my RPO. So am I to understand that you guys are essentially rationalizing that trade-off with these offerings? So I would look at it slightly differently. I think that continuous availability and RPO, if you will, or non-zero RPO, like you're saying, are a little bit at odds with each other, right? By definition, being able to run active, active in two locations in the ultimate case of reads and writes happening at two sites and then having failures in between and truly having a continuous availability model with that is still an unsolved problem in computer science, and it has a lot to do with speed of light. I hear you guys are working on that, though, deep in the labs. We're really hard on that, and we'll let you know as soon as we have it solved. Come on, Google, help us out here. But for sync environments, for the regional campus level, metropolitan level, there's a ton of that going on. And what we're seeing is that with the consolidation of data centers into larger footprints, you end up with actual failure domains within the data center. So you have fire cells, you have different floors in the data center that are treated as if they're virtual data centers. And it makes a lot of sense. We have a lot of customers that are deploying this really within the same physical footprint, but it's providing the same capabilities and resilience that they're looking for traditionally between a campus or between two metropolitan data centers. So when you talk about the services, are you primarily focusing on that metro synchronous distance type of problem, or? Yes. V-Plex Metro is the backbone to the way we're thinking about this. And it is, I think, for our purposes as it relates to engaging with our clients, the basis for the conversation. But in the interest of sort of going out a little bit further as it relates to some of that altering the way we think about disaster recovery, to specifically answer a question you had, I'd love to see it at some point where we just stop considering RPO and RTO and doing a business impact analysis is altered in such a material way that you would not do it in traditional fashion. That's our objective. So let's just talk about that a little more, because I have a question. I had a note about the BIA, do I? Is that what you're doing? You're going in and doing a business impact analysis? Could when you do that, you always have the RPO, RTO conversation. How much data are you willing to lose in business versus business? What are you talking about? Right, right. Until you start talking about the cost of what it'll be to actually get all of the data. Right, then all of a sudden, ah, plenty, a full day maybe. Sure, maybe you can find. The reality is, as it relates to those items, those are a traditional business continuity view of the world. I would like to think, and I think aspirationally where we want to be with continuous availability is helping our clients move well beyond that construct. So the idea that they're thinking in terms of recovery time objectives in a traditional sense, sort of a way of the past, where the future is going to be more about how seamless is the switch, how little is impacted, and how minuscule are the changes that they experience as a result of some level of failover or engagement of an active architecture. Okay, so given that you're not necessarily prescribing the parlance of traditional RPO, RTO, what kind of language are you using when you go in and do these assessments? So everybody's got to forgive me a little bit because unfortunately I spend enough time around the insurance guy. So I'm trying hard to get away from that language. I think the way to think about it is, we'll talk about what I would call the top end of the spectrum of cost of uptime. So it will very much become a nuance of the cost that one or a company is willing to bear relative to an extension of five nines of uptime. That will be a function of business need. So transaction support, use of data, the value placed on accessibility and use of data going forward will be the compelling part of the discussion rather than just I need something, an application within a two-day span or a one-day span. I think you'll see more of a, how do I prioritize which decisions are made when and which transactions are supported immediately or in a slight delay. You know, that's an interesting point because in all my years of following this type of industry activity, and it's always been fascinating to me, you hear people say, you got to speak in the language of the business. And then they turn it to an RPO-RTO discussion. I don't know a lot of business people that even understand what RPO and RTO is. And what you're saying, Matt Allen, if I understand it, is we want to talk in terms of the value of the application, the business process maybe, you know, that touches that application and how critical it is to the business, how much revenue it drives. I mean, are those the types of discussions that you're having with customers? Those are exactly the conversations we're having with our customers. And I think you hit on the point of all of this, our release and the backdrop of the continuous availability offering, the set of services, and frankly, the way we're lining up with Vplex Metro. The idea is to alter the discussion, move away from simply a technical answer to a technical problem and into a discussion of business problem being solved by a combination of technical solution and process redesign and or, you know, reconstructing a business need over a different expanse of problems that we're trying to help our customers solve. In this instance, I think for the first time, get to see the convergence of both technology and business need and frankly just timing as it relates to clients and or customers' needs. The backdrop to this, no matter how you cut it. And I sort of gloss over the need to talk about RTO and BIAs and that sort of thing. But the reality is every customer, no matter which customer it is, needs their data in a way they never have before. The hockey growth as it relates to their dependence, their need and their consumption of data has never been the same and it's never gonna be the same. It's gonna continue to grow. Their need for uptime is only accelerating. It's not going to alter, you can't go back. So in this instance, it's very much a business solution that we brought a technical, I think very specific technical solution to a business problem in a way that I would argue I haven't seen a solution like this since I've been engaged in roughly 20 years of consulting in this area. So I want to dig into the solution a little bit more, Matt Waxman. My question to you is you mentioned recovery point before. So instantly I'm thinking about dialing up or down the level of service that's required based upon my business need, the discussion that we were just having. So I presume recovery points part of this offering are not necessarily or how's that all fit? Yeah, yeah, actually before I get to recover point, I just wanted to add one more point to the previous conversation, which is I think a little bit of the history of how we got here, add some color, which is we've been out having the Vplex conversation now for a couple of years and getting great adoption of the technology. But what we've seen is that it actually triggers exactly this conversation, which is yes, it's really important that I address this from a storage perspective, but I really want to look at how I transform my business into a model of let's talk about uptime. Let's stop talking about RTO and RPO as a technical element, let's talk about uptime. And what that's driven is obviously creating the service and the consulting around it, but the conversations that we're having with customers now are about tell me how to build the solution. What do I need in terms of load balancer? Is what do I need in terms of infrastructure? What apps are best suited to it? It's a totally different conversation than a let's talk about just the storage infrastructure. So I think that's an important context around it. Right, and essentially you're taking a service's view of it. It's, you know, in this world of everything as a service, you're talking about availability as a service or recovery as a service, I mean uptime as a service. I mean, I'm maybe inventing a new term in the fly here, but talk about that notion, because I'm assuming that what it allows me to do, let me put the premise forth is I can then tailor the service for the application of the business requirement. And my service level and my consequent costs are gonna be affected by that service level that I choose. And you can, as I said before, dial up or dial down. I presume recovery point is a key part of that flexibility. And obviously the substrate here is Vplex. Right, right, so on the recovery point piece, what's really interesting about recovery point, right? There's two core aspects to recovery point. One is around disaster recovery, which we've been talking about. The other is around operational recovery. And operational recovery is all about in the case of a corruption, a great example, right? Or a virus or that type of thing. How do I dial back to your point, to a point in time where I knew I had a good image, right? And operational recovery applies to continuous availability, the same that it does apply to disaster recovery. So we see a lot of synergy there between recovery point and Vplex, and that's why we built the integration that we have. Not just because of the DR component, but the operational recovery too. So as you build out these services, how do you envision the service level agreements changing in terms of what the organization, what the IT organization is committing to its customers? How is that discussion going? And what do you predict there? I think there's an immediate response that I'm seeing the, it's one of expectations management. What's realistic to achieve in the near term? What's more of an extended roadmap? What are the requirements that are going to be imposed on the IT organization going forward to fulfill, help the business fulfill their objectives? For me, that's a balance that you always see. I think the IT component of the organization having to manage. With continuous availability, you'll see that enhanced. I think it's like almost anything from a technical perspective, where application functionality is added in a way that adds to or enhances the business, helps transform the business, the expectations only grow. It makes the IT side of the house a little bit more difficult to manage. But I think the reality is the solution set is now advancing in a way that it is practical and you'll see the client and or the broader marketplace uptake this conversation in a way that they just haven't in the past. Yeah, I think one way to think about it is, I don't think success at the end of the day in implementing continuous availability is a guarantee back to the business of 100% uptime. I think this transformation is really about changing the economics of transitioning OPEX into infrastructure with a different model for the infrastructure. I don't think it's necessarily the primary goal just to go back and let's get to 100% uptime guarantee. That's not the goal here. That will hopefully be a side effect, a positive side effect, but it's really about just making a big transformation the way stuff has been done in the past. So the transformation is the economics and let's touch on that first. So it's cheaper to provide continuous availability. It's essentially the obvious point of this announcement. But the second is that the other piece of the transformation is the, it's not one size fits all anymore. It's you can tailor the availability services to the business requirement. Is that, am I correct? Is that another part of the transformation or is it too early to think in those terms? Yeah, I think it's multifaceted, right? There is an availability angle to this. There's also an asset utilization angle, right? When you put in a continuously available infrastructure, you get the benefits of availability, a different model, but now you actually have assets at two locations that you can be using on an active basis, right? And so when you look at that from an economic standpoint, right? Taking great example, we love to talk about is Oracle Rack, right? It's a solution that absolutely fits into this model, you know, works great with the Plex, and now you have the ability to take workload, mission critical workload and distribute it between two sites, right? You just took a whole bunch of assets that were sitting there passive waiting for a failure to happen, and you've been able to put them into the pool of resources. So there's a lot more to this than let's just go for that uptime play. So there's a TCO, there's asset utilization, there's greater flexibility, there's just better IT in general, okay? There's one additional note to this, though for me there's sort of an atomic level view of this from just a business perspective, and it's the idea that most of our clients are balancing some level of risk in this decision-making process. It sort of nets out to some version of risk reward. So uptime at some level of assurance is designed to either manage or mitigate some level of risk of being down. So as a general rule, what you'll see is different clients and or different customers to your point at a very specific level of need, making cost benefit and or risk reward decisions on a regular basis as it relates to what their uptime requirements are. In some instances, there will be a need for very little or zero or nominal downtime. In other instances, there's a different level of tolerance but it all boils down or tracks back to some level of what's my tolerance for risk and or some level of downtime or disruption to service. So Matt Allen from an assessment standpoint, what's the view of granularity? Is it the application? Is it the business process? Is it the linkages between the two? Is it the degree of interdependencies across the application portfolio? How do you squint through all that? I think it's always, for me anyway, it always maps back to some level of risk associated with fulfillment. So very literally whatever the organization's objectives or some level of fulfillment as it relates to the objectives of that organization, anything that is viewed as a risk or a disruptive element as it relates to execution of transactions or execution of decisions based on data. Anything that maps back to that becomes the driver to this broader continuous availability discussion. Continuous availability becomes very much a, and it's an oversimplification, but a control to the disruption risk. It's a means of managing a risk that's very much about a disruption to services. The real debate or discussion then becomes, well, do I need to have a certain type of uptime to literally eliminate or more effectively manage the risk? So I infer that to be a business, the answer you gave is to me anyway, business process. Well, however the customer defines it. That's right. Okay, now this is where it gets complicated. Underneath that business process is this spectrum of applications and IT infrastructure and people and other processes. Is part of the assessment to dig into those and try to help customers understand that? Or is that sort of a given? And then you're sort of layering your methodology on top of that. That's very much a part of the process. The intent is to better understand, again, some of the traditional view of dependency on different applications and or gaps in infrastructure or requirements from both an application and an infrastructure perspective going forward. So those gaps or identified issues always have to map back to that business case that we were talking about. And so for me, our service, this release and the backdrop to all of it is about how we help our customers manage those gaps and continuous availability to the back. Well, Vplex is the back. And I presume you're charging for these services, right? I did. There's not a lost leader, right? Okay, so how do you charge? Is it TNM based? Is it some percent of the implementation? Or how does the customer go about thinking about what this is gonna cost? Sure, it's normal consulting services. So as a general rule, it's some version of an hourly rate against a predefined scope of services that we'll engage in with the customer. We, in every instance, sit down and make sure we're very clear about the scope of the engagement. We've articulated the timing tasks and deliverables and set up pricing accordingly. In some instances, we'll engage with our customers from a time and materials perspective. But as a general rule, it's an assessment service that's designed to give them a sense of scale and scope of what they're gonna have to do from a broader roadmap perspective. So it's sort of pricing in what I would call typical assessment service sort of terms. Okay, and then Matt Wexman had a question on Vplex. You mentioned you've been in the market now for a couple of years. Can you just give us an update on Vplex? How's it doing? Customers, any kind of guidance that you can give us on the uptake. And then the use cases and how this initiative expands those. Yeah, so I'd love to give you an update and everyone out there. So we've had phenomenal adoption of Vplex. We have been in market now, like I said, a little over two years. We are in every major vertical and every major geography across the globe. And it really comes down to this core use case of continuous availability. That's what we see the majority of customers using as the initial play with Vplex. But there's a ton of other use cases that are resonating well. Tech refresh is an obvious one. Going in and being able to non-disruptively, refresh your storage infrastructure is one that every customer deals with. And everyone's looking for an easier solution around that. You get that with Vplex. Being able to do workload mobility. When we initially launched the product, we talked a lot about Vmotion and the ability to pick up a workload and not just move it between two boxes within the data center, but actually do it over long distance. And so that use case also fits really well. And really, so the conversation is typically, there's a particular business that needs continuous availability is a great one to get in the door. But then when it's in there as an infrastructure, there's just a ton that you can do. And we're seeing that across the board manufacturing, financial services, healthcare, you name it. They're all love and be Vplex right now. I wanna switch gears a little bit. I know it might be going a little long but I'm just really interested in this topic. So hopefully you guys got a few more minutes you can spend with me. I want to talk about the cloud generally and specifically public cloud and Amazon web services. We've seen Amazon make a big push into the enterprise with the re-invent conference in November, basically going after guys like you. You're the evil empire and they're the savior kind of thing. We love it, right? It's a good disruption and good marketing. But at the end of the day, customers have to make a decision. They don't want to act as though Amazon's all bad because then they look like naysayers. So they have to embrace AWS for the right workloads. At the same time, to get a capability is what you're speaking of here out of Amazon, forget it, you'd get, you know, you would need, email us, we'll get back to you kind of thing. And that's sort of the model. Now that's evolving and there's an ecosystem there but my specific question is what are customers telling you guys about the public cloud generally and AWS specifically? Where do you see that fitting in to a customer's portfolio of choices? And in particular, how do you see your new capabilities differentiating from that? Well, I think the first answer and it's a bit of an oversimplification is kind of stepping back and talking about it from helping our customer or our client perspective. To understand and or assess the benefits and the risks associated with engaging in or engaging a cloud provider at one level or another. No matter how you cut it, that conversation always maps back to some level of uptime or assurance of service or provision of service that meet certain parameters. And generally speaking, what we found is that not all providers are talking about this in equal terms. In many instances, service level agreements are not meeting I would consider to be good practices, not best practices, good practices and some of that conversation. And right now it appears in large part because of sort of the newness of the provision of services in a broader context to the market. And just specifically talking about the terms of the cloud service for public cloud. Public cloud, yeah. And that's not specific. I mean, that's just- It's understandable. I mean, a huge scale. It's on a business risk and liability that they would have to take on. So you can understand why they don't put that risk in writing. That's right. But the fact is- Now the demands are there and the demands are growing and that's only going to become more acute as time goes on. And we see the marketplace adopt continuous availability and more regular or uniform fashion. So you'll see the providers having to adhere to some version of that at some level, no matter how you cut it. Yeah, I think availability is at the core of all of it. When you look at the transition to the next wave of applications and all the mobile stuff that we all use every day, availability is becoming more and more a core part of what we all expect. So wherever that's deployed in the infrastructure, availability is going to and is quickly becoming a core tenant of that. So a great example, well-known publicly, was the Netflix outage. Outages. Outages. Yeah, I see that in the politics. It impacted me personally, which I was very upset about. But- You didn't have Amazon Prime? No. I can't do. Yeah. But it's that level of availability. And people think about that as, well, I can tolerate downtime, but there's a cost associated with it. And I think that you'll see these types of technologies and this evolution, whether it's continuous availability in the extreme or not, availability is going to be at the core of that transition. So the service level agreements that your customers within a private cloud environment can offer their internal clients significantly more stringent, I would presume, than what you get from a public cloud provider. Plus, they're going to get fired if they have that many outages. So it's a different world. And I guess I've said, look, Amazon's another tool in the CIO's toolkit. Use it. Right tool for the right job. And it sounds like you guys would agree with that. But if you think about it, and again, my apologies for constantly trying to boil this to the base level business case. But the reality is, and Matt can, I suspect, site chapter inverse the same way, but I don't know, as recently as seven, eight, 10 years ago, I would speak at different conferences and make the comment, do you want to be the guy who takes credit for being out for three days? That doesn't happen now. That's inconceivable now. We couldn't, a dream of a scenario in which you'd have any kind of a material outage, now it's fractions of time compared to what we were used to. You've become conditioned to that. And again, that only becomes more acute as the business case grows. But the, and I think you guys said something about this in your press release, the value, even though it's sort of minuscule improvement, let's say in terms of the number of nines, right? But the value of the applications and the data is now so much greater than it was, has been historically, so the numbers are larger, and you're so much more reliant on IT. I think it was the Forester study that sort of, that was one of the key findings. And so we all know that. And so my question is when you do the business cases, are you essentially measuring the reduction in expected loss from an outage? Is that kind of the dollar and sense of this? There's multiple cuts at it, but it's the savings and reduction of loss, but not just savings and reduction of loss, savings and reduction of redundant activities, processes, and technologies. Here's the part of the case that for me, I think is missed. No matter how you cut it, especially when you move outside of the IT, the infrastructure stack, there's a ton of business processes and people and resources and efforts to assure some level of uptime or to assure that there's a continuity of operations. In this instance with continuous availability, we're offering an alternative to a lot of that redundancy. So we can give you very specific dollar value savings in terms of what you no longer spend on, or we can give you dollar value savings in what you were eliminating, or the risk you are no longer exposed to. Well, so I'm reluctant to say that's one's hard dollar, one's soft dollar, because if you go down, websites down and you can't take orders, that's hard dollars, but there's, let's call it IT savings, right, in terms of redundant processes and procedures and hardware and software, and then there's the sort of business impact, which I would think is telephone numbers, comparatively speaking, but it's a harder sell to the CFO, presumably. That's right, but again, I think in that instance, there's a constant balance between the risk reward or the cost benefit decision here, and as a general rule, I'm finding more and more within the IT organization, no one wants to be that guy. No one wants to be the guy that said, well, we saved a few dollars here, and we had a little bit of outage last year during the holidays, and frankly, no one wants to be that guy because that guy won't have a job very well. The reality is they've got to find a way to come up with solutions that are, I think, a much more compelling story from a cost benefit perspective, specifically as it relates to uptime. Uptime is the compelling driver now in a way that it never has been unpassed. Right, all right, Matt Wexman, last word. Maybe just summarize your thoughts and then we got a break. Yeah, I first really appreciate the time. I think it's a great opportunity. What we've built here, both as a company and just shift in the industry, I think is really revolutionary, and we're seeing customers adopted in droves, right? And so I just expect a lot, a lot of interest in this. I think this is the tip of the iceberg, and you'll see a lot more coming down the pipe too. Well, gentlemen, Matt Wexman, Matt Allen, thanks very much for coming on theCUBE. Really appreciate everybody watching. This is Dave Vellante, this is theCUBE. Thanks you, and we'll see you next time.