High Availability is synonymous with Cloud. The entire application developer community believed so, till the Amazon incident in 2011. After that day, there are multiple ways and opinions that the application developer can choose to follow while ensuring high availability.
Lets’ start by looking at what the providers offer today:
- Packages: There are multiple models\packages offered by the cloud providers that advertise varying percentage of availability. Of course in many cases, your application can survive with less than 6 nines availability, if it is not a critical application and you don’t want to spend a lot of money!
- Availability Zones: Providers also offer availability zones. These zones are insulated from failures in other zones, as they do not share infrastructure with other zones. As a result, by choosing machines in separate zones, you can add to the availability of your application.
- Deployment Configuration: There are various choices in deployment configurations. This is more based on what type of deployment you are comfortable with.
- There can be a single powerful machine hosting everything – web\app server, databases etc. The advantage here is in case of failure, the entire machine can easily failover to the replicated mirror site. Obvious disadvantage is the performance bottleneck.
- There can be the standard configuration with web\app servers as well as databases on separate machines. In fact, as cloud is advocating distribution, this type of typical deployment is in favor nowadays. Here, in case of failure, there is a possibility, that your machines may end up in geographically dispersed areas, giving rise to network latency. To counteract this possibility, the providers have a feature where you can group your machines, so that on failure, the entire group does a failover to replicated mirror site.
- Geographical Locations: The providers also let you have control over geographical locations of the purchased instances. This way, in addition to avoiding the network latency, you can also achieve higher redundancy.
- One Stop Shop: The providers offer everything that the application may need in one place. Eg. In addition to EC2 servers, Amazon also offers EBS \ S3 databases. They also provide services like Elastic Load Balancing as well as Cloud Watch and Auto Scaling. Opting for such setup will enhance the availability of your application multi folds.
However, in case the Amazon incident is a trust breaker for you, there is always the way where you can take care of the high availability on your own. There are various configurations suggested, where people have diversified their deployment configuration to involve multiple cloud providers. The idea is, you make a machine from one cloud provider a hot standby for your server currently residing with another cloud provider. This is a costly proposition, and the synchronizations, monitoring and failovers need to be managed by you.
In spite of the Amazon failure, I would anytime recommend trusting the cloud providers’ high availability claims. This is because of the huge infrastructure as well as sophisticated algorithms and strategies that the providers have in place for ensuring the high availability. After all, nothing is perfect – even 6 nines of availability does result in a possible downtime of 30 seconds per year 🙂
