Today Microsoft Windows Azure SQL Database Services briefly went offline. At that moment I realized that the project
I was working on had a major flaw! Without lives services our development team was at a stand still. This isn’t the first or last time cloud services go offline. Services can go offline for a multitude of reasons and it’s up to us to be ready for such an event.
This is also a great time to think about Disaster Recovery Plans! Take some time and ask around. Does your company have a Disaster Recovery Plan? If the answer is NO, be sure to make the priority #1 because these things never get much attention until its too late! Furthermore,downtimes are extremely costly for any organization and for its customers. The costs of going through a downtime, range from a complete stand still for the entire company to very localized stand stills. In any case downtime costs money.
In the instance where ALL SQL Database Services go down at once, there isn’t much you can do unless you have copies of your data off the cloud, which also happens to be publicly accessible. Building a copy of your
40GB ~ 150GB SQL Database can be costly, but it is possible!
If you are in North America + Europe, replicating a 40GB database whose data changes often, will have a bandwidth cost of about $4.20 USD/Day. Be sure to use the pricing calculator to estimate your costs of operation.
Make it a priority to look and implement local replication of you Cloud Production Databases using SQL Data Sync.
SQL Data Sync is built using the Microsoft Sync Framework and will require the installation of the SQL Data Sync Client Agent. This agent will transfer your data between the Windows Azure SQL Database and you on premises installations over HTTPS.
Replication can be configured as
- Bidirectional
- Windows Azure SQL Database => On Premises
- On Premises => Windows Azure SQL Database
Today I learned That
I should talk about this topic more often and that I should never put off Disaster Recovery Plans to later.
Had I setup the replication at an earlier time, I could have shifted the service configurations to point to my on premises SQL Server Database instances and could have continued to provide services for the customers. This change could have taken place quite fast and most customers would not have noticed the shift.
Shifting configurations to point to an on premises SQL Server Database instance will incur bandwidth costs and will also create latency. Keep in mind that a slow system is better than none at all. Being at a stand still without the capacity to provide services to your customers is a horrible place to be!
Alexandre Brisebois ☁ 