I read an interesting post about moving your database to the cloud (or, rather, hybrid cloud) and was surprised about the elements the writer chose to determine whether your database is a candidate for that type of infrastructure. (Here’s a link to the post)
It’s hard to determine just what elements are most critical to considering a move to the cloud, and hybrid cloud adds a few new variables to the mix. There are some good points in the post, and I think too that far too many people make the move to the cloud/hybrid cloud (from now on just “cloud” unless a specific thing is applicable) without really considering whether their systems and applications are going to benefit from the environment.
One of the things mentioned in the article that I do take some exception to is security. I think security requirements are a key element in any system, and certainly, if you have some sort of custom security requirement that is quite unusual, perhaps it could impact whether you should consider a cloud implementation. However, I believe that the major providers all have outstanding security environments and tools available to you, certainly that rival things you may be considering for on-premise
The biggest security thing I see impacting implementations at this point is addressing the storage of information and international audiences for that information. In particular, if your application stores information that is managed differently depending on the nationality of the person owning the data, or your company locations, it’s worth understanding the storage options you have. Do you store information only in the US? Only in Canada? Only in some other country? A case can be made too for storing information in the country of origin – in other words, in the country where the user that generates the information is located. There are regulatory issues that can play a big role in this process.
Overall, though, determining whether your database would benefit, I think, comes down to a few other factors.
– Is your database usage “bursty” (technical term)? If so, that may drive your system designs. This is because if it’s due to “flash” usage, you may have to size accordingly. If it’s due to patterns, you may be able to dynamically size, or if it’s due to ongoing growth, that’s an issue that you can address with instance or database engine sizing. There are different complexities involved with database sizing options, and it should be a consideration when you look at the infrastructure (and therefore resources and costs) associated with the move.
– Are there regulatory issues (compliance, privacy, access controls) that will drive your configuration? Some are more intricate than others to implement and should be a consideration when it comes to your database platform and the difficulty of moving to the cloud, or modifying your systems to support that move.
– Uptime and availability requirements? Not because you don’t have options available for high-availability, or good backup and recovery options, but they’re different and it’s very important to determine what you’ll need to do. Can’t go down at all? Need specific windows for recovery? It’s not that the cloud will or won’t help your availability story, it’s that it may be different and may not support your application or database requirements in the same manner, so it’s important to understand differences.
– Are there other services that you’ll need because of the complexity of the applications using your database? Key management systems? DNS? Custom ports? Tools for management and monitoring?
Overall, I’d say a “standard” environment for your database won’t be the issue. It’s the more specific and fringe things that you may have requirements for that may cause headaches.