Scalability and Service Continuity Are Not Equivalent in Cloud Computing

Scalability and Service Continuity are not equivalent terminologies in Cloud Computing. A service of cloud computing is generally provided to customers to ensure a capability to scale, but the fact remains that there are people who can  consider a cloud service as a safety net for interruptions. The idea to protect against interruptions and failures is achieved by hardware redundancy, preparing copies of applications or web services hosted in the cloud and they are ready to use only when there are problems internal infrastructure. Scalability is a feature of Cloud Computing.

Scalability and High Availability Architectures

Most enterprise-class data centers have been designed keeping in mind about possibility of the interruptions in service, relying on the so-called High Availability Architectures. Scalability means that a system of hardware and software, increases its performance with the addition of resources or other nodes / computers in a defined area in a proportional or linear pattern. Within a hardware platform this implies for example feeding circuits, a high level RAID, etc. At the network level or above this requires redundant network elements: load balancers, switches, routers, firewalls, all these elements must be duplicated to ensure fast failover in case of failure. This generally requires configuration and support for IP addresses distributed, allowing redirection immediately after noting the presence of a break in the default location. Scalability of a system measured with scaling factor.

Highly Scalable Architectures and Scalability

Most of the cloud environments are designed not with the paradigm discussed above but to ensure the Scalability, the elasticity of the service to supply the immediate resources subsequently to a user request. An instance of load balancing is required and works in much the same way as high-availability architecture (less redundancy). The load balancing service behaves as a virtual application, with at least one instance behind it. If demand grows new instances are made available and added to the service to ensure that performance is not penalized. This process is also able to go back eliminating instances in view of a reduction in the service request.

If the only available instance falls, this architecture does not provide high availability for the application because it takes time to launch an instance of replacing it. Although there are ten instances and in case one fails, the performance and availability for some clients may be affected. But if we consider, how the system responds to changes in demand for resources, then it stands out positively. Scalability and high availability are not interchangeable, we can not assume that an architecture is able to provide, at the same time scalability and built-proof fails. There are two different problems and are faced with different architectural designs.

One can combine these two architectures to achieve a system which is highly scalable, with high availability, in which the redundancy is used to ensure availability while the elasticity is exploited to achieve scalability by reducing the supply time and costs by implementing a resource model which is flexible and virtual. It ‘important to understand the difference in these architectures especially when we look at the cloud public as an option, because it will in most cases a service that ensures scalability, no resistance to failures.

Relying on a scalable architecture to safeguard high availability or do vice versa means making improper use of this technology.