So you’ve decided to embrace the benefits of the cloud, worked the numbers, presented to your partners and convinced them of the benefits of making the leap. So now what? That was the easy part!
My road to embracing the cloud and more specifically, DR as a service took over a year of planning, presenting and vendor selection. Initially, it was a pure cost-saving move, but I quickly found that what looked like on paper an easy cost-saving migration was anything but. Now don’t misunderstand me, moving our DR to the cloud is the right move for my firm, but it was definitely not as straightforward as I thought. Below I'll try to outline our path.
1.) The Problem: When we first moved to a fully redundant DR model a little over five years ago, offloading services to a third party was just not cost effective for someone our size. Storage and compute power were simply not priced in a way that made long-term sense. We ended up going at it the old fashioned way, buying hardware and replicating over a large site to site to a third party data center.
Now at this point I should stop and give you a little background on my firm and some of the pressures we faced in making these moves. Smith Debnam is a smaller firm without the luxury, or burden depending on your perspective, of multiple locations. As such we didn’t have the option of simply turning one of our other offices into our DR site. On top of that the, types of law that the firm focuses on presented us with a unique set of regulatory and client security standards. Smith Debnam aside from the more traditional types of law has a major practice focused on retail debt collection. Yup were the people sending you letters when you don’t pay! Well hopefully we're not sending YOU letters, but you get the point. So as such, we prostrate to the altar of PCI-DSS[1]and align all of our security and operational standards to it. So what? Well because of the level of PCI we fall under we are required to house any off-site data in a tier 3 data center with all the trimmings, of which there are not very many within a reasonable distance.[2] All of this is to say we couldn't just pick our favorite VAR and move into their colo facility and call it a day.
So as it does, our hardware started to age out and not keep pace with the performance requirements we had set. Our choices were to replace and keep with the current and tested method or look again at moving it all to a third party hosted environment.
2.) The Process: It’s a pretty straightforward project to upgrade a virtual cluster, so I won't go into that much other to say we explored that option and the 4-year This time I wanted to make hosting work. Not only for the relative simplicity of administration but also to take advantage of all the cloud has to offer around dynamic expansion, data growth, security, and compliance. Getting this stuff off my network and out of the scope of my physical security limitations was a key driver as was TCO.
The market of full of providers of DRaaS and most of them would have met our requirements from a PCI perspective. Where it gets tricky is when we started to architect what we needed and how we needed to connect things like our phone system and call recording systems, for example, in the event of a disaster. We decided to keep some of the hardware in our existing colo such as our subscriber node for the phone system and our offsite backups. Because of this, we needed to create a link back to that location from the DR cloud environment. While not complicated to achieve it was another line to buy and cost to bare to tie it all together across different providers. After considering all the options around this one requirement, we decided to continue with the vendor what we have or physical colo with and take advantage of their interconnected datacenters rather than push this traffic across the internet.
Once we got the vendor locked down it was time to figure out exactly how much data and compute we would actually need. I was spoiled by having dedicated DR hardware, and my team had to sit down and really look at the trends over time around usage and data change. We were all pretty surprised how lean some of the systems were that we thought were our workhorses while others surprised us with their amount of change. Once we had the baseline down, sales crunched the numbers and came back with a surprisingly reasonable monthly number. After all the horse trading and haggling its was almost a third less expansive over 4 years than continuing wit ha physical setup. Running it against our on-prem analysis, it was pretty clear going hosted would be more flexible AND cost effective! Double win!
3.) Installation and migration: So if you go into a project like this thinking in and out in 30 days, think again. Were four months into installation as I write this and have just finished our initial sync to our tenant. Our first drill is in three weeks so that will be the test of success so far. The most significant speed bump we experienced was a backlog of implementations that we had to wait for. While we waited, we were still able to plan and work with the project management team to make sure when it came time to seed data and test connectivity everything would be as ready as we could make it and all the interconnects and VPN’s would be up and ready to go. The beauty of as a service offerings, at least from my perspective, is the ease of administration after you get rolling. After all, isn't that the point? Offload the carry costs, admin work and monitoring to someone else and sit back and enjoy the green lights on your dashboard. And while it's still too early for me to make a final conclusion if past is prologue it will all work as planned and hopefully start our movement to push everything out over time.
4.) Conclusion: Moving
any workload to an as a service platform should be based on deliberate and measurable business goals. The stakes are high in most cases and when it fails it fails spectacularly. But… With the right partners and done with realistic goals leveraging IaaS, PaaS or any of the other aaS offerings has the potential to be transformative in the way we can provision services and maintain availability. Working with your clients along the way, helping them understand how this can be a benefit to their relationships with your firm is also important. Many large institutions embrace cloud services but don’t reflect that in their MSA’s or client agreements. Get in early and make acceptance a priority.
aaS is not for everyone or every workload, but where appropriate it has worked for us and given us access to tools and platforms that a firm our size would never have been able to create on our own. That alone is the key benefit of aaS and the future of ours and many others datacenter plans. Good luck!
[1] https://www.pcisecuritystandards.org/
[2] https://en.wikipedia.org/wiki/Data_center#Data_center_levels_and_tiers
#Security