How to run databases in the cloud and not feel pain
What are the problems of running your business's databases in the cloud? Not as many as you'd expect
Along with fileservers and email systems, databases are core to most companies. They generally contain key data which is both frequently accessed and commercially sensitive, and hence there is often understandable trepidation when it's suggested that the cloud is a good place to put them.
This really need not be the case, though. In its basic form a database is really just another application, so as long as you go through the usual series of sensible considerations, there really shouldn't be a problem.
For all but the smallest databases the primary consideration when accessing the data is the connection speed between the client that's using the data and the database server itself.
If you're putting the database in the cloud, then, you need to be careful to consider the connectivity between you and it. The remote nature of your data doesn't automatically mean that you can't connect to it at the right speed, though: with decent quality Internet connectivity there's no reason at all why performance should be sub-standard even if you're only connecting to the database via an Internet-based VPN. I've used Internet-based VPNs as secondary links for point-to-point Metro Ethernets, and few users have ever complained about performance in the event that we've failed over to the VPN. High-speed Internet connections are common, reliable and inexpensive. And if you're really paranoid and prefer to spend cash on a leased line then that's fine too – sign up with someone like Amazon who, for a very modest sum (eg about £500 per year for a 100Mbit/s port, plus usage charges), will let you run a direct link into its premises.
If you're putting the database in the cloud, then, you need to be careful to consider the connectivity between you and it
As well as considering physical connectivity, remember also that WAN optimisation is a fantastic way to improve the performance of your connectivity. Personally speaking I'm a huge fan of the RiverBed optimiser range, but that's primarily because it's what I've used for years (other WAN optimisers are available). Optimisers don't compress data – they use cunning algorithms to reduce the actual data volumes transferred, and application-specific code modules do clever stuff at the TCP level to spoof packet acknowledgments and the like and artificially make the round-trip time appear lower. The big cloud providers all have WAN optimisation options, which you can exploit as long as you have the right kit at your end of the link.
If you're using client-server applications and the connectivity between server and client is ultra-critical, you can think slightly laterally and put both components in the cloud by hosting the client applications on a virtual environment and using one of the many virtual desktop mechanisms to access them from afar. This is common practice in global companies that have to host their applications in a particular geographic location but it works a treat for all companies with this requirement.
We've mentioned connectivity to the application, but what about connectivity between the components of a database in a resilient setup? You clearly need to be able to replicate data between the primary and slave databases, which means that the link between the two needs to be able to keep up with the data flow. Interestingly, though, because database replication isn't all that chatty – it's largely a one-way data blurt – this doesn't necessarily mean that you need a particularly low round-trip time. On the contrary, you just need enough raw bandwidth (which could be provided in part using WAN optimisation) to physically carry the volume of traffic in the required time.
No discussion about cloud wouldn’t be complete without a mention of security. It’s a topic that seems to get potential users a bit hot under the collar. To a certain extent, it’s a bit overstated. Yes, you're putting your data in the cloud and you do need to consider the security of it just as you would any other application. And perhaps you're a little more cautious with your database than you might be with, say, your email server because the database contains proprietary secrets, or sensitive client data … but , the truth is, you should be equally concerned about all aspects of your data. If you've gone through the proper process of considering the security implications and you've been diligent in your choice of provider, that really should be enough – you oughtn't to need to do something special for your databases.