 All right, good morning, good afternoon, everyone. Really excited to have a panel here today, business discussion, generally around how to build a case for OpenStack in your organization. And I'm thrilled with the three panelists because I think you're gonna hear a lot of different perspectives. Let me just do really, really quick introductions just to my left here is Matt Haynes from Time Warner, Andy Salem from RGB Networks, and Doug Soltees from Bud Van Lines. And instead of them giving you their bios, what I thought I'd do is have them each go through just quick their infrastructure today and what they're doing with OpenStack. So Matt, why don't you go ahead and start. So yeah, I work at Time Warner Cable. We have a fairly expansive infrastructure, as you can imagine, supporting both the IT side of our business, as well as what we call the subscriber side, which is the side that serves all of our video, broadband and phone to customers. That entire set of infrastructure is fairly classical, and it's in the way it's put together and deployed today. And so we're on a mission to revolutionize that, put that into more of an on-demand as-a-service offering and OpenStack is one of the tools I'm using to pull that off. And before Time Warner, you were at HP, building out some of their OpenStack efforts as well. Yeah, I ran the engineering group for the HP public cloud. So a lot of experience. I've been around this game for a little while now. Andy. Andy Salo, so I run product at RGB Networks and we build basically IP video delivery products, software and hardware solutions and we sell to companies like Comcast or Time Warner or I guess just Comcast or anything. No comment. And we build a lot of software solutions and we've started to basically cloudify all of those and I can describe what all those mean, but really for us it was just a natural evolution of where we were heading with our products and how our customers were deploying their products and what we wanted to do internally from a hosted environment and testing perspective. So I think what we're interested in to talk more about is you actually go into customers with your product and install with OpenStack. That's right. Yes, so very interesting. Doug? So in our environment, we're an end user of OpenStack technologies. Most recently we started using Swift and we're actually trying to look at Seth. We've always been trying to keep ahead of larger moving and storage companies or one of the largest independence, but competing with their resources means that we've gotta be maybe a little bit more bleeding edge so we certainly virtualized way back in 2006 earlier than other companies. Today we're looking at how can we cloud enable our drivers out in the field? How can we better manage disaster recovery, storage rollouts, everything like that. So we're a classical customer changing over to the OpenStack approach as it's maturing against proprietary systems. So interesting, so from a van line perspective, let's just start with you. It's a somewhat traditional kind of enterprise company. What was the core problem really that you were trying to solve with OpenStack? So we didn't have necessarily a core problem. We have problems all the time and we constantly are solving those problems. And so way back it was virtualization. Our servers are getting to be too much. Today it's more we have an infrastructure that's aging because computers are durable products. And so as our backup disaster recovery was aging, we were saying, you know, this isn't keeping up. The issues that we're having is a couple of years ago we got hit by the hurricane on the East Coast, Superstorm Sandy. We had a little bit of downtime there. We're nationwide and it just seems like with the blackberries, with the iPhones, we've really moved even though we're an independent van line to being a 24 hour operation. There are times when we're down at three o'clock in the morning for maintenance and actually get emails from users. So I needed to improve our disaster recovery. And so we started most recently using SWIFT as a backup disaster recovery replication and just something that's really durable because at the end of the day, previous solutions we've used whether that's tape and a lot of tape, you know, tapes fail, drives fail. There's just so many points of failure and really as we move forward, we want to do the same thing for less costs at a faster delivery speed with less points of failure. And that's what we recently found with SWIFT and that's what we're looking at with CEPH and other technologies. And what, from a disaster recovery standpoint, there's obviously, there's a lot of solutions out there that could solve your problem. What drove you to SWIFT? What drove you in to OpenStack and looking at that as an answer? So, you know, we always have to look at proprietary, so I'm saying right here, and I just heard somebody's phone go off with an email message. I'm sure I have emails right now from EMC, Dell, HP, saying, hey, let's go to lunch and talk about this proprietary solution that we can offer you. And that's what we're using today. When we start looking at a technology like SWIFT, it's more because we went out and we started looking at what technologies can solve our problem. And the hard thing is, they don't have the same marketing team. It really has to be more on us to figure out these OpenStack technologies could enable us. And then we have to build a business case around these technologies. So for example, recently, we were looking at these deduplication products and every company out there has them, EMC, Dell, HP. When you're looking at these deduplication products against OpenStack SWIFT, they've got these marketing magics, right? So you're buying, let's say, 30 terabytes, but you can get a, in certain environments, a 300 to one deduplication. You can get a 50 to one, or you could get a this or you could get a that, and that's their proprietary magic. Whereas when we look at SWIFT, we know we've got this many objects, we've got this many terabytes, and we've got this price per terabyte. And so comparing them isn't really apples to oranges. It can really make it tough to determine the actual TCO of an OpenStack solution. Really it came down to how many times we've done forklift upgrades. So time and time again, we've deployed a solution, whether any sand that we've ever used. They've told us that, ah, in the future, you'll just be able to scale up, scale out. And then a few years later, they went, wow, we don't offer fiber channel drives anymore, you have to have a completely different, you know, infrastructure. We don't offer this, we don't offer that. And we've always gone back to the market, which I think any company should do, and said, hey, it's been three years. Staying with my existing vendor may be the right choice, but more often, there's something new, something disruptive out there. And in this example, most recently, it was SWIFT, it was the disruptive example. That's great, we're gonna come back to TCO here in a minute, cause I think it's a good topic, but Matt, let me ask you again, just to do contrast, big service provider, big infrastructure, a lot of probably, you know, different groups inside that have different opinions about what the direction is to go. What was the problem, I mean, you came in, obviously a believer, haven't been at HP in terms of what, you know, OpenStack could do. So what was the problem there that you saw that you could go tackle and talk a little bit about that? Sure, you know, and it's important that I've said before, I wasn't hired to deploy OpenStack, right? So, you know, I sat down and Michael Joy, who's the CTO's office, and he said, look, we have three problems, you need to go help fix. One is, it's too slow to develop and deploy applications. It's way too slow. You know, we live in a world where it can take weeks to deploy a VM. The second problem is really around scaling our infrastructure with reliability. We have so much infrastructure, we have lots of data centers, but it's difficult to present to the application developers at Time Warner a consistent model of HA and DR capabilities. So a lot of applications get built without all of those features built in. So that causes outages, which bothers Mike. And the third one is cost. He said, look, I spend too much money, and then he showed me how much we spend. And I said, yeah, we do spend way too much money on infrastructure. And so that's- And is it money, both CAPEX and OPEX? Both, both CAPEX and OPEX. We're a very heavy CAPEX shop. Basically what cable companies do is they leverage CAPEX to print money. But it's a good business model. But those are the problems we're trying to solve. For me, OpenStack is one of the tools that's well suited to make progress against all three of those. It lets us deploy with low cost because of the commoditization of the hardware underneath. The intelligence software layer drives the smarts down to commodity hardware. It allows, obviously, us to deploy a system. The entire infrastructure, we're turning it over to as a service, what we call a cloud, which to me has the properties of self-provisioning, multi-tenancy, metered, automated. And so all of those help drive fast deployment as everyone who's used OpenStack knows. And it allows us, and I'll point to Swift as well, we are deploying Swift in two national data centers with one ring and four copies. So not only do we have local HA in each data center, we have DR, I can lose a whole data center. It's really solving the reliability. Yeah, and we can offer that then to our customers who are all the application developers of Time Warner Cable in a real consistent way and say, look, we've enabled you to go build DR applications now. Put all of your state in Swift at some point, you don't have to leave it there, right? You can bring it back up into Sendr or whatever you need, glance, but if it's there, it's available. We can lose the entire data center and you have it, right? So those are the problems we're solving. That's great. So, Andy, just to contrast with you guys, very unique where you're actually using it almost as part of your product. That's right. You know, it's interesting. We've, you know, we listen to our customers and so people like Time Warner are doing exactly the thing that Matt is highlighting of, you know, they want to leverage commodity hardware that they know they can purchase on different cycles, different budget cycles, and then put whatever software applications they need on that commodity hardware and deploy it whenever needed and do it much more quickly. So what we saw was, number one, we were listening to our customers and number two, because of the way we've taken our kind of just our software product direction, we were building, we were going from really kind of point products, such as transcoding and packaging to more solution sets of products for doing like NDVR and ad insertion. And when you do that, you basically start to have an ecosystem of applications that need to talk to each other. And when you have an ecosystem, what better way to orchestrate that ecosystem than through a cloud-based application like OpenStack? So it became, it was just a natural fit for our product direction and a natural fit for what our customers were already trying to do in their environment. That's great. So I wanna mention everybody too, I'm gonna try and take some questions from the audience. So if you have some, you know, start thinking of something and I'll take some here in a minute. But let me turn to actually how you got OpenStack moving inside of your organizations. Because I would say all three of you are still relatively early adopters in the process. I mean, there are lots of good production use cases now with OpenStack, but you know, it's probably not necessarily the easy decision I should say inside of an organization. Maybe Matt, maybe start with you. I mean, just in terms of kind of, how did you build that case? Was there pushback? What were the friction points? And kind of, how did you think about that inside the organization? No, I mean, to be honest, there wasn't a lot of pushback. The, you know, the objectives I mentioned were given to me and it was up to me to go figure out how to solve it. So really I had to convince myself that this was the best approach. Having familiarity with it, knowing this beast, if you will. You didn't have any pressure to, I don't know, AWS, hey, it's a great solution, hey, you know Matt, why don't you go, why, you know, I hear these all the time. In our case, again, we're a little different. Maybe we are a networking company. We are an infrastructure company, right? So outsourcing that to AWS is not, I don't think it's the right decision for a company. We should have that core competence. And so, eventually, I think, you know, now in the back of my mind, am I planning to, you know, compete with them on price level internally? Absolutely, right? We have to make those decisions to be ready to do that. Right. But, you know, there wasn't really, there wasn't a case that I had to make to the management. They've given me the confidence. They've given me the gun and I'm trying not to hit myself with it. They've given you the rope. They really have. And I mean, maybe it would have been harder had I not done this for a couple of years back in when it was really hard, sort of Diablo time. Yeah, yeah, yeah. But no, it's, you know, I had the confidence that this would be, and I said it's one part of a broader solution we're deploying. It's not the only thing we're not just doing, not replacing everything we've got with OpenStack, but it's an important component, not just because of the cost metrics it brings to the table when we deploy it, but also the philosophy that it gives our developers for scale out architecture, for rapid development, they need that as well, right? They're looking to move in that direction as well. When you get a VM once every six weeks, you don't really have a scale out architecture in your head when you're building, right? So it drives that mentality as well. Did you have, I would imagine, just back to the AWS point about being agile, if it takes six weeks to get a VM, I mean, I love how you describe your customers, the internal application developers, because I love that mindset. Were people starting to look to other ways? Yeah, some, yeah, some of the folks, especially some of the folks, I mean, it's relatively a sort of traditional business, right, it grew up in the 80s, and so the people that do the core applications have been around for a while, but you know, folks that run our website properties, and a lot of the new applications that are being developed, you can get your time-warner lineup on an iPad. We encode it and stream it live, you know, the IPTV part of our business is really growing, and all of the services that support that kind of application are modern, and those are the folks that are dying for something like this, right? So yes, they've been poking around at AWS, and you know, wondering when we could get something. So they're kind of lined up. Well, they'll become your biggest supplier. And we're, you know, we're almost open for business form, so. That's good. Well Doug, I imagine in your company, it was probably a little bit different story. Yeah, we're constantly battling. So, you know, whenever I spend money, it's, our core competency, we're a trucking company. So if I spend $100,000 on a solution, I just took a truck off the road, and that truck is a revenue generator, whereas some of these other companies on stage, you know, they're making revenue from the technology, and that's not where I'm at. So first I have to convince somebody that we need this core competency. So let's say virtualization. We did that many years ago. Once I convinced them that we need this core competency, then the next thing is it needs to be supported, and that can be kind of tough. When we virtualized at the time, Microsoft was not supporting Exchange and a bunch of business critical applications on virtualization. But virtualization was such a critical technology that we did anyway. Today, when I go into the board and I'm arguing for a product like Swift, if I convince them that we need this new backup disaster recovery solution, they're going to say, well, what's the Swift? Who's Swift stack? And I go, well, they're gonna give me the enterprise support, and they're gonna go, but this other company's using EMC, and I just golfed with them the other day. In fact, we're trying to get into their accounts. Why not use EMC? And the thing that will happen is I'm gonna lose that argument because my company gives a high level white club service and they expect our customers to pay more for the service we're providing because it's a superior service. And they see the same thing. When they hear the name brands, right, they hear IBM, they hear HP, they have, they hear EMC, they're expecting that same white club service and that we're getting what we pay for. So the argument that I go in with more often than not is not to say that this EMC product against this they've never heard of before, right, Swift stack product. What I do is I go in and say, we need better disaster recovery and EMC has these products, but have you heard of the cloud? And of course it's in the Fortune magazines and they've all heard of the cloud. And I go, we can send the state up there, we can hold it, we can have it longer, it's not proprietary, it has all these different things. And cloud can be EMC in an argument. So it's kind of like rock, paper, scissors, right? EMC can get beaten by cloud, but EMC could be, say, Swift stack. However, once you've convinced them that we need to do disaster recovery that's dynamic and using a cloud-based technology, then you come back a few weeks later and say, we have determined the cloud-based technology we want to use. We want to use Swift stack because we want to have this cloud be a private cloud on-premise, still get the cost effectiveness, all of the things we sold you on in cloud. And so now you're not having EMC or Dell or NetApp battle against your smaller technology. You've convinced them of a, you've kind of gone non-linear. You've convinced them that they need this other technology and then you've picked the proper provider of that technology. But you certainly still want support. Obviously, with going with Seth, we're looking at Ink Tank. We use a ZFS-based NAS today. We buy our support from Accenta because we like these technologies, but we need support. The only other thing I can comment on with that is I was in a session yesterday and it was on Seth with Ink Tank and Dell was there. And at the end, they had a reference architecture and that really helps because I can tell you that I had to make a much bigger argument for an Accenta a few years ago, but today doing Seth or an Accenta, I can maybe eek it in where I go, well, we're going to compare the HP left-hand solution to the Dell Accenta or the Dell Seth solution as soon as they hear that bigger name company and you can show them that reference architecture. All of a sudden the butterflies in their stomach kind of subside a little bit, but it's definitely, every project is a battle and I don't want to say at the trick my board because I hope they don't see this, but you do. You have to bring them to the answer you've come to and sometimes that is still staying with the proprietary technology. We're not looking at open compute today because we have virtualized on VMware and just because Microsoft did not support them at the time, now it's all supported. To move now to open compute, well, gee, I already have a big investment. It's working well and I don't want to lose some of that support or pay the additional licensing. Right, right. Well, that's great. The, may it's a good time to just transition to this concept of, you know, kind of TCO seems to be a big discussion point with OpenStack when it's getting deployed because you're shifting to what looks like potentially a very agile low-cost open source solution, but as we all know, there's no free lunch. And certainly in their early days, Diablo days of OpenStack, it was kind of a bag of bolts, took a lot of work to put it together. It's got a lot better today. Maybe, Andy, you can just start off talking. How do you guys think about TCO and making that case and kind of the trade-offs internally, because obviously you could go with a turnkey solution and it would work, but, you know, they talk a little bit about that. Yeah, I mean, so internally we, I'm almost on like two different fronts. There's sort of the internal selling, you know, and then there's the internal selling for how we position our products, right? So, and part of it's just the internal selling is like eat our own dog food, right? So we want to, you know, be agile, deploy quickly. You know, the same things that I was positioning for the board, you know, I had that similar board discussion that was a little bit challenging, but you know, the same thing that you have to position for here's a go-to-market approach for, you know, how we should do this. It turns out that that actually is a great thing to do internally as well and just how you develop the products and how you kind of deploy both internally and in a hosted environment. So, you know, some of our customers face the same challenges of, well, I want to go deploy something and have the design and engineering group create that environment, but then I have to go turn it over to operations, right? And so they have that challenge of they want to replicate that in an operational fashion. We have that same challenge internally of, well, I gotta develop it and then I have to turn it over to system test and then eventually to customers. And I want to do that in a very cookie cutter way if possible. OpenStack is great for that. If I'm orchestrating with heat or anything else for that matter, but using heat templates to basically create an environment on the fly and build and tear down environments, it makes my internal development job a lot easier. And did you internally, one of the things I hear often in talking to enterprise customers is, yeah, I have a lot of VMware trained engineers, but I don't have anybody that knows OpenStack. How did you guys deal with that internally? We had exactly that challenge, right? So, in fact, both in customer environments and internally, we use VMware all the time, right? And so it's a different, it takes a different set of a, just a different way of thinking, but one of the things that we did was created an internal, both internal and external, a deployment tool for making a turnkey, right? So I basically, we had a team that created a tool that would just deploy OpenStack, build up our environment, our instances, our software applications, put it all on it, configure it, all you have to do is press a button and then go get a cup of coffee, and then you come back and you have an OpenStack environment. So just making it easier for people to adopt it was pretty key. But how about in your organization? I imagine, you know, that whole concept of TCO, understanding those, the hidden costs and kind of thinking through all of that, it's probably very complicated and hard to get your arms around. How do you guys think about that? No, TCO is difficult with OpenStack, right? You know, I always feel like a balance sheet and sometimes I say, you know, open source is free, but it's not cheap. You have on the positive side of the balance sheet, you have things like, it drives commodity hardware. That gives me better opportunity to work with multiple vendors at that sort of most basic level that they sell. You know, it certainly has attractive license fees for the software itself, right? So there's a number of things that make it, that are positive on the balance sheet, but anybody looking at deploying OpenStack really has to also focus on what I'll call the hidden costs, right? The hidden costs are things like, you're gonna have to have support, right? So while the software itself might be free, you're gonna pay Canonical, you're gonna pay SwiftStack, you're gonna pay Ink Tank, you're gonna pay the folks to give you the support, the red hats, the folks who are gonna stand behind this software and who know how to configure it and set it up and run it well, right? You're also gonna have expenses in building some internal expertise, right? You know, it's certainly at a level we run it, you know, when you're sort of see, not to give away actual numbers, but in CS notation, you know, big O notation, we're in the O 100 range, right? So that covers me from like 100 to 1,000, if I remember. You know, when you're on that kind of many nodes, you know, you have to have an internal competence and it's a different level of effort than it would be, say, to run, you know, a VMware product out the door. So you'd be willing to invest in, say, a team that's gonna have that. There, you know, the problems that, the biggest problems that plague Diablo, a lot of those exist today, which are the operational issues for OpenStack. Standing it up to get Nova running is not hard. Operating it is difficult, right? The operational issues of operational monitoring, you know, really good billing and metering, all the issues it takes to run this thing take a skill set and you have to be willing to invest in that. So when you're looking at OpenStack, yes, it's free, but you're gonna have costs. You're gonna have support. You're gonna have free like a puppy, not free like beer. Yeah, exactly. And you're gonna just have to, it can be challenging to put those into all into a spreadsheet, although we do try to, you know, my management does like to see numbers and so we have taken a swing at putting some of these things down for them to do comparisons for TCO against the vendor product. But they are sometimes surprised that there's actual costs there. I thought it was free. Okay. How do you guys look at TCO? Is it similar kind of way? Oh, definitely. So they're definitely letting in costs. Again, I echo, you have to use support, right? I don't want to stand up, you know, a Swift install that I have no support on. I don't wanna stand up, you know, a ZFS install, any of those. Because at the end of the day, you don't wanna be the guy holding the torch when something goes wrong and things do go wrong. I would echo that, you know, definitely trying to get people with training. So, you know, it's much easier to get somebody with VMware training. I think a great thing in the OpenStack and the community is the ability to get training kind of first. So for example, we don't have any Chef deployment and yet next week we're sending people to Chef training. I guess you could do the same thing with VMware, but again, going back to it runs on any hardware. So we have test servers that may not meet if I was gonna be doing Open Compute today, that may not meet, say, VMware's HCL list. And if we download it and we try it free, you know, we might crash and have a bad time. Whereas, you know, KVM's gonna run fine. We're gonna be able to do that. I'm sorry, we're gonna be able to kick the tires a little bit better because just because it's OpenStack doesn't mean that we're gonna do it, you know, because it's cheaper. It's gotta work, we've gotta be confident in it. So we will have normally probably about a six month testing period. And that's more than when I call EMC or I call NetApp and I say, hey, I wanna test your sand. They're pretty glad to send me something small, but they're not glad to let me test it for six months. You know, they wanna, if it meets these requirements within a certain period of time, you will purchase. Whereas I can grab commodity hardware so my engineers can take stuff home. They can play with this in VMs and their own environment. So it really kinda helps the whole kick the tire approach and see, you know what, this isn't up to snuff yet. We're gonna wait on it. We're gonna go ahead with this proprietary solution. Do something else. Yeah. Annie, let me come back to you. When you were looking at OpenStack and thinking about it, what were the biggest deficiencies? I mean, from looking at it as an enterprise customer, you're a real user, you're not, you're running a business. This isn't about a developer, hey, it's cool to play with. You got a job to do. What struck you as big, what's really deficient today with OpenStack? Yeah, so there's a few things, you know, I would say, first of all, Havana and now Ice House have made some of these things better already, but things like, for instance, you know, the orchestration. Havana was really when you guys stepped in. Yeah, Havana, you know, we started out with Grizzly, but immediately with Grizzly, you know, we were focused on the orchestration aspect and so Havana, including Heat, was a big plus. You know, but it's really the orchestration. It's, you know, it's monitoring challenges with the salameter and making sure you can kind of monitor the environment. It's, you know, for video, there's an aspect of multicast, right, and that's something that's not talked about much in an OpenStack environment, but you really need multicast to deliver video. So that's, you know, that's still actually an ongoing challenge. So there are a number of things that, you know, need to be solved, but that's good for people like us because then we get to be the ones that solve that. Right, so you're actually working on contributing things like multicast, you know. Yeah, absolutely. We're doing things within the networking realm just to try to make sure that our applications work well and therefore video applications in general work well in an OpenStack environment. So Matt, you mentioned operationalizing. It sounds like that's probably when you think of OpenStack and the biggest efficiencies, you know, tools, the tools are great, standing it up, the basics, but really the operational. Yeah, I think operating a large-scale deployment is challenging, right, the community is in a great job with not just the services, but a lot of tools, but sometimes, you know, again, unlike a vendor who takes a very directed path to putting out solutions, you know, the open source community, what's great about it is it kind of moves in a chaotic and parallel fashion and things come out with many options and eventually a winning choice usually survives, but, you know, it does leave us choices sometimes. So sometimes there's no choice or too many choices. There's still deficiencies. I go back to operational monitoring as one of these. You know, when you're running it and you're running it at a large scale and you're trying to figure out on my services up, are they healthy, is everything working? You know, you have to collect information from the message queues, from the logs, on every host and everything else and there's no good way yet to, although I think our friends at HP have recently released something into the open source community that helps to address that block, but those are some of the gaps that they're starting to get better, but it's still operational complexities of a large open stack deployment are still challenging. Yeah, I mean, you think about how many large scale open stack deployments there are today, there's just, there's not that many. There's not that many. So, you know, people are learning. I know. I wrote this blog post last week called End of the Beginning where I kind of feel like we're past the stage of anyone's questioning that it'll work, but we're not quite at the stage yet where there's, you know, massive large scale deployments. I will say though that more people are willing to take this on first time than, you know, you've seen. You have, you know, just the attendance of this kind of a audience, you know, this kind of a conference shows that people are, I think, invested in this is gonna work. Yeah, just in that post I was mentioning, you know, about 10,000, I was at re-invent last year and there's about AWS re-invent. There's about 10,000 people there. I know what they're saying about 4,700 here. So, yeah, it seems real. Well, let me turn to the audience. Are there any questions from that insist? Yes, sir. That's a great question. Let me just repeat it so everybody can hear. So, the question was, you know, talk a little bit of ROI in terms of how am I gonna make a return on my investment against open stack and how did folks make that case internally? Well, you know, again, for us, it's fairly straightforward because the business model is set up to make money off of infrastructure. That's true. So, for me, if I lower the cost of the infrastructure, I increase the ROI, right? But the engine is already set up to leverage infrastructure to deliver services that we charge for. So, for me, that's sort of built in. Let's say two quick ones for us were, number one, of course, enabling a service and helping sell our software applications as a service and as a solution set. And the second is really agility internally in developing and testing. You know, working in a continuous integration, checking this kind of model, deploying new builds, new releases, getting things out there very quickly and getting through automated testing done very quickly. You know, not everything for us has a good ROI. I gotta be honest. So, tapes are still one of the cheapest mediums out there and you'd be hard pressed to beat a truckload of tapes. You know, I got big trucks. You fill a truck full of tapes and you drive it from New Jersey to California. I bet you I can be any fiber link in the world with the amount of throughput because I can get that truck there in a week. So, you know, it's hard. You have to start looking at things that aren't dollars and cents. I have to start saying things like, well, you know, this tape, you know, we do our backup at night and this tape sits there in the morning and it's, let's say, the Saturday morning backup because Friday night, you know, the tape drives ran. When does that go off-site? Well, that goes off-site, you know, Monday. Well, what happens if everything burns down? Now, they don't like to hear that. Nobody wants to hear that. But it's the same argument we make for getting a generator for anything else. A generator only has an ROI if you have a disaster. You know, disaster recovery only has an ROI if you have a disaster. And a lot of the new technology makes it simpler and easier for me, but you're playing a statistics game. And so I got to be honest, sometimes the ROI is worst and you got to win the argument by giving the technological benefits or the hey, we can sleep better at night. Yes. Yeah, I kind of want to follow up that last train of thought around disaster recovery. So clearly tapes are cheaper, but is there some kind of a justification of operating a cloud environment that makes disaster recovery easier, more reliable, better, whatever, that helps in the justification of moving down this path? I think you guys have kind of talked about that. I thought maybe you could kind of elaborate on how much of that is part of your justification. So for us, we're a different situation than other companies. We have offices nationwide. So I have the space and I have the electricity. And so that's kind of cheap for us. And we have our headquarters in New Jersey, we're very centralized. We set up a DR site in California, but then we start to look at scenarios. What happens if Jersey goes down in California? What happens if we get a virus because say we use Ubuntu? Let's say somebody writes in a Ubuntu virus or maybe use Red Hat, somebody writes something like that. And it gets propagated through. So now we need secondary systems. We need to replicate and we need to go to, say, Swift and have it do and let's call it out-of-band replication that hopefully will survive a virus that attacks our sand, a virus that wipes out something like that. So a lot of it's around the fear that we're seeing today, right? And XP law support and we'll probably see a whole bunch of viruses related to that and Heartbleed and the stuff that NSA does. So as my company moves forward, even though we're a moving and storage company, Americans want to be able to pick up the phone and talk to one of our coordinators right now and they don't want any downtime. And yet we all know that in our server environments, we need downtime and things like being able to motion VMs from one machine to another mitigates that. But certainly for us, we went from having headquarters and offsite backup to having a headquarters and a DR site to now having headquarters, DR sites, a DR site and having our data distributed amongst all of our other sites because at the end of the day, it's affordable and tapes go bad and yet data running on hard drives that's being CRC checked doesn't and that's a winning argument. That's great, yes? So I guess something fundamental. You're sitting in front of a board, not your company. Chairman looks at you and goes, what's a cloud? Secondly, why should we be a cloud enabled company? And third of all, why should we be doing a cloud internally rather than relying on somebody like Amazon to do it for us? I'd like to hear from all three of you. So back to what's a cloud? You gotta pick your term, right? So when I had EMC duke it against cloud, well right now, clouds in all the magazines. But if I had said cloud two years ago, they would have gone what? So you've gotta make sure that you're keeping up with what the latest is and Forbes and whatnot and use the proper technology. So if your CEO doesn't know what a cloud is, you should know that ahead of time and you should use a different analogy in your meeting. So you need to make sure that you can definitely win that argument is what I'm gonna say. And then also when we talk cloud, we are using the Amazon, right? They are the name brand out there. That's what he's thinking of when he hears cloud. And then we start to make the points for, well, we wanna keep it in-house. We wanna use Swift stack. We don't wanna use the S3 cloud. But let's face it, even when I go through documentation of how to get my backup product to talk to the cloud, there's seven pages on how to connect to S3 and there's one on Swift or an open stack product. Right. Anybody else wanna? Well, I'd say just real quickly. For me, it's knowing your audience. So internal selling is key, knowing where they're coming from. So if they don't know cloud, then I talk about IDC, with the market going from 47 billion to 107 billion by 2017 and that 451 report says that number one driver of cloud is internal private cloud for enterprises and kind of show the, kind of paint the picture first and then it's talking about if there is a TCO element or ROI, then I'm gonna talk to that. Let's get one more quick question and then we'll have to end. It's just a quick follow-up. So I know that at TWC you said your business is infrastructure, so you're not really interested in sort of using hosted solutions. But at RGB and Bud, given some of the deficiencies you mentioned, I'm wondering if you're constantly sort of reviewing the trade-offs with going to a hosted solution that's perhaps more mature, that doesn't have some of the same issues, because things like DR and those sorts of solutions are available through availability zones and replication and things like that in hosted clouds as well. So just curious if that's something that you continually consider, are you really set on a strategy to use an on-premises cloud with OpenStack? No, I would love to put everything in the cloud cloud. I'm still a little fearful of the cloud. So let's face it, if Anonymous is in the room, if they wanted to attack Bud Van Lines, I'm pretty sure they could get through our defenses. And I'm sure they're attacking Amazon, all these other people today, and they're not getting through. But when I put my data in the cloud with somebody else's more important data, I've kind of, I've grouped myself in with that potential. So again, I'm not saying that my security and my uptime is really, really high, but compared to, say, Amazon, but we know that a few years ago they had the problem around Christmas, Netflix, other services going down. When we went down for the hurricane, it was acceptable to our customers to say, hey, we had a day of downtime failing over and switching around because Superstorm Sandy hit the East Coast and we were one of the first companies back online. But if in the middle of a nice sunny day, we're down because we're using this cloud and they're down, that's not, they don't forgive that. So I would love to, and I think we will, and I think that's the future, but I need the cost to come down and I need, I sell some butterflies in my stomach. Well, let's, let's, let's end that when we're sensitive every time. Listen, I appreciate everyone giving us your time and especially the panelists. So let's give a big round of applause for everybody. Thank you very much.