posted on Thursday, December 04, 2008 7:15 AM
Deploying applications in a cloud computing environment, whether private or public, requires a bit of proactive thinking on the ramifications of a dynamic, on-demand environment, particularly when considering the impact on application session management.
Consider that today, application sessions are often relied upon to remain in memory, on the application server, for hours. Persistence is achieved by storing the session in a file if necessary on the local server rather than in a database. This is particularly true of web applications developed in scripting languages like PHP that do not require a separate application server. But users who start some task are often distracted and come back later to pick up where they left off. As long as the environment supports "sticky connections", that's okay in today's traditional environment because the session is still hanging around, in memory, for whatever amount of time the administrator has configured as the "session time out" value.
Now move that same application into the cloud. Application instances are brought on and off-line on-demand; when additional instances go idle, they are taken offline so that some other application can use the resources. But what happens when a user who was interacting with an application gets distracted and comes back later, and in the meantime the instance they were attached to has been taken down?
Yeah. Go directly to jail. Do not pass go. Do not collect $200.
They're going to have to start over, and invariably this is going to lead to some frustration on the part of the user. Do I start now so I can finish before the meeting? Before lunch? Before I leave? Before Don shows up with the donuts?
This may not be a problem with some providers, as it is possible that applications are not considered idle until all sessions are "gone". But that raises other concerns, such as the potential increased costs associated with maintaining those sessions in memory "just in case".
It may be the case that this is one of those issues that goes in the "CON" column of cloud computing, that impacts the decision on whether a particular application can or cannot reside in the cloud. Or you may have to use a database-backed session configuration for the application to ameliorate this particular issue. Shared database-backed sessions have the effect of mirroring application sessions across all instances, ensuring that sessions are available regardless of whether the instance that created them is still executing. The negative to this approach is that it requires a database in which to store the sessions, and that database will need to be always available, which may increase the compute resources you need. You may be able to take advantage of a cloud computing provider's database services, such as Amazon's SimpleDB for session management rather than your own. Regardless, it is generally agreed that database-backed session management is the best way to handle sessions for a number of reasons including security, session portability, and scale, giving you even more reason to consider database-backed sessions rather than relying on in-memory session management, especially if you're developing using scripting-based languages.
Generally speaking, moving from an in-memory model to a database-backed model of session management is transparent to the application. It is often the case that developers aren't even aware that sessions are stored in the database rather than in-memory as it requires no changes to the code and is a configuration level option for both web and application servers. But it is important for developers and administrators considering deploying existing or new applications in the cloud, as session management can be problematic if it is not well understood before deployment.
IMAGE COPYRIGHT PARKER BROTHERS
Technorati Tags:
MacVittie,
F5,
cloud computing,
session management,
mirroring,
database,
on-demand,
development,
internet,
web,
applications,
application delivery,
blog
