Welcome to Ask the Experts, brought to you by CloudServicesUniversity.com. In this video, William Hiatt, CTO for RapidScale, discusses Common Mistakes Customers Make Around BCDR with Intelisys’ SVP Cloud Transformation Andrew Pryfogle. Find out more about how to solve your customers’ BCDR concerns from William and the RapidScale team here: http://rapidscale.cloudservicesuniversity.com/
| Andrew: | Okay guys. Man, these ask the expert sessions are becoming real highlights of the whole University certification tracks. Keep getting great feedback from you guys on that. Let’s ask now back to the studio, a returning guest, one of the smartest guys I know around cloud, Mr. William Hiatt, CTO of RapidScale. William, always great to have you bud. Thanks for jumpin’ in again. |
| William: | You, too. You too, Andrew. I enjoy the conversation as always. |
| Andrew: | Very cool. We’re talking about BCDR, Business Continuity Disaster Recovery, and you deal with a lot of customers that are trying to design a legit kind of strategy around this, and some perhaps feel like they’ve already designed a strategy. I’m curious. What are the common mistakes that you uncover with customers when they’re looking at business continuity and disaster recovery? The common mistakes when they’re designing that kind of a plan |
| William: | There’s really a handful of things. Generally, in our experience, it revolves around connectivity, for an example. I always like to tell a customer that it’s one thing to have it in place, and everybody thinks they have it, but, do you test it? That dovetails into the connectivity that says well you have maybe one location, or you have five locations, or twenty locations, now how are users going to access your DR? That goes into a lot of different things. It depends on, again, the applications and the infrastructure and the environment, connectivity. That’s really where we start is the most common mistake. |
| Andrew: | At the core of what you’re talking about there, it sounds to me like, around restoral, right? |
| William: | Yeah. |
| Andrew: | They check the box, yes I’ve backed up everything, but they don’t think through, how would I have to restore it in an emergency situation? |
| William: | It’s not only restoral because, again, it’s … I won’t say easy, but relatively easy to just have everything come up, but you have application interdependencies. Are we protecting ourselves from rolling data corruptions? Do we have backups that are DR sites? Can we go back four hours or one hour or different intervals? All that depends on the failure scenarios. The BCDRs are really … On one hand, it’s a really simple conversation, the other hand, when we get into varying degrees of failure scenarios, there can be a lot of different scenarios that we need to take into account. It really depends on how in-depth the customer wants to go. Is it something as simple as saying, we have our service here or do we want our service to be functional over here at the DR site? Or is it, we have individual applications or database corruption or individual failure scenarios that we need to account for. |
| Andrew: | Yeah. Got it. I’m always surprised when I deal with companies that are still using something like tape backup as their data backup solution. Why might that be a foolish path to take? |
| William: | I’m going to slightly agree and disagree. We actually love tape, because tape is still one of the cheapest mechanisms for storing data. In long-term archival retention, tape is a great strategy. We do some things internally around that, so we love tape from that perspective. When you get into DR, when time is of essence … Tape also isn’t very fast, right? When we’re dealing with time being of the essence, I got to get back up and running, I need to be back up and have an hour of data loss, things like tape and some traditional mechanisms are just horrible. That’s where we got to look at real-time replication. We got to look at having compute capacity available. Again, with service like RapidScale, that doesn’t become an issue. For long-term archival retention, which is again, part of a backup or BCDR strategy, tape still has a play for some environments and some of our customer base. |
| Andrew: | That’s fascinating. Even an older technology like tape, that’s a really excellent point. If you’re not going to be accessing the data, and you just need to be able to know that it’s stored somewhere, and that in a pinch, if you ever had to go find it, you could, tape has actually a really good fit for that it sounds like. |
| William: | Absolutely. There’s some public cloud that do some things around tape, as well, like, I can’t believe I’m going to use this word, but like Amazon Glacier and things like that. Again, it takes you hours and hours to get the data back. I come from the customer side, and what we used to do … this is probably seven, back ten years, we had about 500 terabytes of data at the time, which is pretty significant amount. We’d do real-time replication, but we had archival requirements. We’d leverage tape silos. We archive. |
| Then we didn’t want to depend on have a single point of failure of the tape because they wear down and some things like that. Then we’d have duplicated tapes and one would get some off-site and we retain one within the silos. It really comes down to … It can be a simple conversation, which it is for a lot of our customers, but in some environments, due to compliance requirements or due to their business requirements, it can become a complex conversation. That’s where we’d love to engage with our customers to drive what that strategy is. Usually, we see it’s not a one-size-fits-all strategy across the entire customer base. | |
| Andrew: | Got it. Perhaps that is the common mistake there, that we tend to oversimplify it. There needs to be maybe different types of backup for different types of workloads. |
| William: | Yep, exactly. That goes back to cost optimization. We would love everybody to pay us for reserve computer real-time replication where they can be back up, but we talk to a significant amount of customers and the lower end of the mid-market on down, that … They’re back up and running within a day. They’re happy. We say, just replicate your data, we retain a couple backups of it meaning you can roll back the real-time, an hour, four hours, a day, and that suits most of their needs, and then they only pay, which is kind of the whole method, the premise of the cloud in the first place. You pay as you use it. Restore their data, we can spin ’em up in a DR scenario relatively quick, but we’re giving them the solution that they need versus just throwing the kitchen sink at it, if you will. |
| Andrew: | Got it. Yeah. Very cool. Makes sense. Again, another conversation where we can customize a solution to meet customer requirements that helps separate us from all the noise. That’s for sure. |
| William: | Yeah. |
| Andrew: | William, dude, thanks man. Always great to have your insights, bud. |
| William: | You too, Andrew. Always love the conversation. Have a good day. |
| Andrew: | All right. Hey guys, that’s William Hiatt. He is the CTO for RapidScale, one of our go-to smart guys in the cloud. Do make sure, guys, lock down some time and go deep on the learning center for RapidScale. They’ve got some great, great information there. We’re seeing a lot of success with RapidScale. Make sure that you’re figuring out where they’re winning. Maybe you have customers where you could win with them, too. Good selling, guys. |
