Does Your Cloud Quiesce? It Should.

#cloud #sdn Without the ability to gracefully shutdown the "contraction" side of elasticity may be problematic

Quiescence, in a nutshell, is your mom telling you to "finish what you're doing but don't start anything new, we're getting ready to go".

It's an integral capability of load balancers (of enterprise-class load balancers, at least) that enables the graceful shutdown of application instances for a variety of purposes (patches, scheduled maintenance, etc... ).

In more modern architectures this capability forms the foundation for non-disruptive (and thus live) migration of virtual machines.During the process the VM is moved and launched in location Y, the load balancer continues to send requests to the same VM in location X. Once the VM is available in location Y, the load balancer will no longer send new requests to location X but will continue to manage existing connections until they are complete.

Cloud bursting, too, is enabled by the ability of a load balancer to quiesce connections at a global layer (virtual pattern) and at the local layer (bridged pattern).

Load balancers must be able to support a "finish what's been started but don't start anything new" mode of operation on any given application

The inability of a load balancing service to quiesce connections impacts not only the ability to implement specific architectural patterns, but it can seriously impact elasticity.

The IMPACT on ELASTICITY

Scaling out is easy, especially in the cloud. Add another instance of the application to the load balancing service and voila! Instant capacity. But scaling back, that's another story. You can't just stop the instance when load contracts, because, well, any existing connections relying on that instance will simply vanish. It's disruptive, in a very negative way, and can have a real impact on revenue (what happened to my order?) as well as productivity (that was three hours of work lost, OMERGERD).

Scaling back requires careful collaboration between the load balancing service and the management framework to ensure that the process is graceful, that is, non-disruptive. It is unacceptable to business and operational stakeholders to simply "cut off" connections that may in the middle of executing a transaction or performing critical business functions. The problem is that the load balancing service must be imbued with enough intelligence to discern that there is a state between "up" and "down" for an instance. It must recognize that this state indicates "maintain, but do not add" connections.

It is this capability, this stateful capability, that makes it difficult for many cloud and SDN-related architectures to really support the notion of elasticity at the application services layer. They might be able to scale out, but scaling back in requires more intelligence (and stateful awareness) than is currently available with most of these solutions.