Welcome!

@CloudExpo Authors: Elizabeth White, Yeshim Deniz, Pat Romanski, Liz McMillan, Zakia Bouachraoui

Related Topics: @CloudExpo

@CloudExpo: Blog Feed Post

Amazon Makes the Cloud Sticky

Stateless applications may be the long term answer to scalability of applications in the cloud

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:

blockquote 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”.


WHY is THIS IMPORTANT?

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.

blockquote_thumb1 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 NECESSARY EVIL of STATE

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 image 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.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

CloudEXPO Stories
"IBM is really all in on blockchain. We take a look at sort of the history of blockchain ledger technologies. It started out with bitcoin, Ethereum, and IBM evaluated these particular blockchain technologies and found they were anonymous and permissionless and that many companies were looking for permissioned blockchain," stated René Bostic, Technical VP of the IBM Cloud Unit in North America, in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
In this presentation, you will learn first hand what works and what doesn't while architecting and deploying OpenStack. Some of the topics will include:- best practices for creating repeatable deployments of OpenStack- multi-site considerations- how to customize OpenStack to integrate with your existing systems and security best practices.
Everyone wants the rainbow - reduced IT costs, scalability, continuity, flexibility, manageability, and innovation. But in order to get to that collaboration rainbow, you need the cloud! In this presentation, we'll cover three areas: First - the rainbow of benefits from cloud collaboration. There are many different reasons why more and more companies and institutions are moving to the cloud. Benefits include: cost savings (reducing on-prem infrastructure, reducing data center foot print, reducing IT support costs), enabling growth (ensuring a highly available, highly scalable infrastructure), increasing employee access & engagement (by having collaboration tools that are usable and available globally regardless of location there will be an increased connectedness amongst teams and individuals that will help increase both efficiency and productivity.)
Founded in 2000, Chetu Inc. is a global provider of customized software development solutions and IT staff augmentation services for software technology providers. By providing clients with unparalleled niche technology expertise and industry experience, Chetu has become the premiere long-term, back-end software development partner for start-ups, SMBs, and Fortune 500 companies. Chetu is headquartered in Plantation, Florida, with thirteen offices throughout the U.S. and abroad.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a member of the Society of Information Management (SIM) Atlanta Chapter. She received a Business and Economics degree with a minor in Computer Science from St. Andrews Presbyterian University (Laurinburg, North Carolina). She resides in metro-Atlanta (Georgia).