High Availability

High Availability is one of the major architectural concerns for any architect. It forms one of the core non-functional technical requirements for any serious service and its deployment. High Availability refers to the feature of a service or application that keeps it operational on a continuous basis, meeting or surpassing its promised defined service level agreement (SLA). Users are promised certain SLA on the availability of a service. The service should be available for consumption based on its SLA. For example, an SLA can have 99% availability for an application for the entire year (assuming 365 days). It means it should be available for consumption by users for 361.35 days. If it goes less than this, there is a breach of SLA. Most mission-critical applications define their High Availability SLA with five nines for a year. It means the application should be up, running, and available throughout the year, but it can be down and not available only for 5.2 hours.

It is important to note here that High Availability is defined in terms of time that is yearly, monthly, weekly, and so on and it could even be a combination of these.

A service or application is made up of multiple components and these components are deployed on separate tiers and layers. Moreover, it is deployed on an operating system and hosted on a physical or virtual machine. It consumes network and storage services for various purposes. It might even be dependent on external systems. For these services or applications to be highly available it is important that networks, storage, operating system, virtual or physical machines, each component of the application is architected and designed keeping SLA and High Availability in mind. There should be a definite application life cycle process that should be used to ensure High Availability is baked from the start of application planning until its introduction to operations. It also involves architecting for redundancy. There should be redundant resources included in overall application and deployment architecture to ensure that if one goes down, the other takes over and serves the requests of the customer.