What Does Elastic Really Mean?

In terms of cloud computing in application environments, elasticity is perhaps one of the more alluring and potentially beneficial aspects of this new delivery model. I'm sure that to many of those responsible for the operational and administrative aspects of these application environments, the idea that applications and associated infrastructure grows and shrinks based purely on demand, without human intervention mind you, sounds close to a utopia. While I would never dispute that such capability can make life easier and your environments much more responsive and efficient, it's important to define what elasticity means for you before you embark down this path. In this way, you can balance your expectations against any proposed solutions.

For me, the idea of elastic application environments starts with the implication that there is some sort of policy or service level agreement (SLA) that determines when to grow and when to shrink. However, just having the capability to govern your runtime with SLAs isn't enough. The SLAs should be applicable to performance metrics directly related to your applications. For example, it may be nice to be able to make operational decisions in your application environment based on the CPU usage of the physical machines supporting that environment, however it is much nicer to make those same decisions based on the average response time for requests sent to your application instances or perhaps the average time a particular message waits in your application's queue. When you have the ability to define SLAs based on these kinds of application performance metrics you can remove a lot of ambiguity that otherwise could creep in when making expansion/contraction decisions.

What's obvious is that there's no reason to have SLAs that cannot be enforced. When I think about SLA enforcement there are a couple of things that come to mind. The first is that the party responsible for enforcement should be configurable. In many cases you may want your application environment to grow and shrink based on the system's autonomic enforcement of SLAs, but I doubt this will always be the case. For example, if you are running in a pay-for-use public cloud environment, you may, in an attempt to keep costs under control, want to insert a manual approval process before the system grows. As another example, you may insert manual approval processes for contracting application environments in a production setting where demand fluctuates wildly. In any case, the ability to configure who is responsible for SLA enforcement is useful.

The second thing that comes to mind with respect to SLA enforcement is that you should be able to prioritize such enforcement. The ability to prioritize SLA enforcement means that you can ensure that conditions in some applications warrant a faster response than in other applications. This is just an acknowledgment that not all applications are created equally. Obviously if a user-facing, revenue-generating application starts to violate its SLA you want that condition addressed before you address any SLA slippage in an internal environment.

Besides the ability to define and enforce SLAs, there are certainly other capabilities that contribute to the robustness of a truly elastic application environment. One area that warrants attention is the degree to which application health monitoring and maintenance can be automated. For instance, when an application begins to leak memory and response times slow to the point that SLAs are violated, it may be more efficient to automatically address the leak by say restarting the application as opposed to adding more application instances.

These are just a few of what I'm sure are many facets that contribute to elasticity in an application environment. They happen to be the ones that bubble to the top for me, but I have no doubt there are others that may be more important for you. If you have your own ideas for elastic application environments I'd like to hear them.