Stateless applications may be the long term answer to scalability of applications in the cloud, but until then, we need a solution like sticky sessions (persistence)

Amazon recently introduced “stickiness” to its ELB (Elastic Load Balancing) offering. I’ve written a bit about “stickiness”, a.k.a. what we’ve called persistence for oh, nearly ten years now, before so I won’t reiterate again but to say, “it’s about time.” A description of why sticky sessions is necessary was offered in the AWS blog announcing the new feature:

Up until now each Load balancer had the freedom to forward each incoming HTTP or TCP request to any of the EC2 instances under its purview. This resulted in a reasonably even load on each instance, but it also meant that each instance would have to retrieve, manipulate, and store session data for each request without any possible benefit from locality of reference.

-- New Elastic Load Balancing Feature: Sticky Sessions

What the author is really trying to say is that without “sticky sessions” ELB breaks applications because it does not honor state. Remember that most web applications today rely upon state (session) to store quite a bit of application and user specific data that’s necessary for the application to behave properly. When a load balancer distributes requests across instances without consideration for where that state (session) is stored, the application behavior can become erratic and unpredictable. Hence the need for “stickiness”.

In addition to web applications relying heavily on state, so too do the APIs used to integrate them with each other and with other Web 2.0 applications like Twitter and Facebook and <insert favorite app here>. So called “REST” APIs today aren’t really REST. We know that. They’re RESTful but they aren’t truly REST according to the definition laid down primarily because they aren’t stateless. It turns out state and application development is not just a concern of application architects and developers these days, but of infrastructure vendors, pundits, analysts, and anyone interested in the evolution of cloud computing and a truly distributed, portable model of application deployment and delivery.

State is, to sum up the viewpoint, a sticking point.

As I see it there are two major types of workloads that a organisation is going to want to run on an external Cloud. The new breed which are built for the new Cloud model. These will scale out, be light weight, stateless and fit perfectly with a consumption based model. Run a few small VM's, with low RAM and CPU consumption, as demand increases the application dynamically scales itself out to meet demand, whether that be user generated or application generated, such as a month end processing run. -- Rodney Haywood: The Granularity of On-Demand Cloud - Today vs Tomorrow 

Stateless. It was something we heard sprinkled throughout conversations at CloudConnect, as well. The best “workload” to run in a cloud is a “stateless” web application. Developers have to change the way they develop applications – they must go stateless. Portability requires (read: would be easier to implement) if applications were stateless.

That’s easy to say but a lot more difficult to implement.

The first greatest and most useful hack involving the web was enabling state for HTTP. Prior to the advent of sessions and state, the web was pretty much like interacting with a technicolor mainframe application. Folks even referred to “pages” as “screens”, in reference to the way in which one statically walked through big iron applications in a very linear and uncompromising fashion. Made a mistake? Not acceptable. “Back” and “previous” were foreign concepts. You had to effectively start over and change the existing transaction, which had likely already been committed to the database (assuming there was one). Sessions provided the ability to allow for mistakes and to allow better navigation options within an application. That’s because the transaction wasn’t committed to the database until the user was ready. Data entered in “step 1” could be modified after “step 4” with little effort on the part of the developer. AJAX has made this even easier, as it makes editing data after the fact (or during the process) able to directly transact with the database on a very granular, i.e. field or column, level basis.

Now, if developers chose to do so, they could certainly employ the ability of web and application servers to leverage a shared session database to remove this sometimes onerous requirement. This would certainly free the infrastructure from needing to worry about persisting connections and make scalable architectures simpler to implement, but it would not make the application stateless. We’d just be moving where the “state” is stored from the web/application server to a database. But that, REST purists would argue, is still not a “stateless” application programming model, which most decidedly states that all “session” data (i.e. state) should be stored on the client. Not in cookies, either, but in the client – as in enclosed in forms or query parameters or in JavaScript object models. From a performance perspective this is not optimal, either, as a “shared” session architecture necessarily requires a heavier load on the data store in which the session is stored. For every request the “state” must be retrieved, which in a cloud computing environment may incur bandwidth utilization and session database instance/row/<insert billing model here> charges.

Storing all state on the client would have an impact on just about the entire infrastructure stack and would also likely negatively impact many mobile applications, an increasingly popular client model that should not be ignored in decisions regarding the amount of data being exchanged between client and server.

Thus it is that “stateless” applications are unlikely to become the norm for some time (if ever). State is a necessary “evil”, though it’s “evilness” is certainly, like beauty, in the eye of the developer. Assuming that stateful applications remain the norm in the cloud means that load balancing services in those clouds must necessarily support the notion of persistence (stickiness) to ensure applications don’t break upon deployment. This also results in making it easier for organizations to migrate non-native “cloud” applications to EC2, because there’s no requirement that the application be rewritten in order to run properly (taking into consideration state/session) in a scalable environment.

Thus, Amazon introducing “sticky sessions” to ELB is a Very Good Thing.