Traditionally, large corporations have either maintained their own data centres, or rented rack space in a data centre managed by another company. Redundancy, in this context, has to be maintained on several levels:
The advent of cloud service providers changes the equation significantly. The provisioning of power, cooling, and system hardware redundancy to meet contracted service level agreements is now the sole responsibility of the cloud service provider. As a result, companies leveraging the cloud need to architect redundancy through networking and geographical measures.
When designing an application for deployment in the cloud, the key determining factors in deciding just how much redundancy to build in are two that often stand in opposition.
1. The criticality of the application to the business
2. The cost of increased redundancy.
For an application that is business critical, the cost of a high degree of redundancy is compensated by the cost to the business if the application becomes unavailable for an extended period. For a low priority application, a reduced level of redundancy is reasonable.
The exact details of how the redundancy might be provided can vary from application to application. Having spare instances that can be brought up when necessary might suffice for some. Maintaining redundant instances, running in parallel across multiple sites (AWS and Azure availability zones, for example) might be reasonable. And in some cases, redundancy across a large geographical distance (Azure and AWS regions) will be the way to go. Having redundancy provided by the cloud provider means that your business can focus on the important matter – ensuring availability of your applications in accordance with your business needs, rather than the infrastructure and plumbing necessary to make it happen.