Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Channels ▼


Coding In the Cloud

Lori MacVittie is Technical Marketing Manager for F5 Networks.

While there's a lot of talk about cloud computing these days -- why you should use it, why you shouldn't, and so on -- there's little discussion on the ramifications of cloud computing and really any on-demand infrastructure on application development. So before you jump into the cloud with both feet, it's important to understand how an on-demand environment like cloud computing affects the way applications execute because there are some gotchas that can come back to haunt you after deployment that don't appear until after the application is deployed.

The Impact of On-Demand

Everyone understands that on-demand means elastic; it's the ability of an environment to expand and contract in real-time so that an application is always available. But how that is achieved has an impact on the behavior of applications deployed within such environments.

What on-demand means in terms of infrastructure architecture is that there is some form of application delivery or load balancing service sitting between users and applications. That service acts as a proxy; it accepts requests from users and determines which instance of an application should respond. Some form of load balancing or traffic management service is necessary to distribute requests across instances of an application running inside the cloud computing environment because the client cannot know when it makes a request where the application is actually running. A proxy allows all users to make requests to a host without caring how many instances of an application are actually executing internally or where they might be.

The introduction of an application delivery or load balancing service into the architecture is often the source of much frustration for developers and network administrators alike. This is because applications deployed into load balanced environments like cloud computing often break with no obvious reason. Requests are sent and responses received as expected, but the application seems to lose data or not be able to find data it did before deployment.

There are three "gotchas" associated with deploying applications into a load balanced environment; one is specific to cloud computing or on-demand environments while two are also problematic for general load-balanced environments regardless of where they are located. Being aware of these gotchas during development lets you address the potential problems up-front so applications don't break once they are deployed

Gotcha #1: Session Persistence

Applications often use sessions to store state and user-specific data needed during the execution of an application. Sessions are generally stored on an application or web server in memory, especially when applications are written using a scripting language like PHP. When there is only one instance of an application running this is not a problem. When there are multiple instances of an application running in a load balanced or cloud computing environment, this can be a huge problem.

Sessions are generally not shared (mirrored) between application or web servers. In an on-demand or load balanced environment, the first time a client makes a request it is directed to a server. A session is created on that server for that user, and the application may rely on information stored in that session to execute correctly.

The next time a client makes a request, the load balancing service may send the request to a different server, based on how it is configured to choose servers. This means the session that was created on the first server does not exist and if the application relied on data in that session, the application breaks. The reason this scenario is so frustrating is that sometimes the client is directed to the server on which the session resides, and the application works as expected, and sometimes the client is directed to a different server with no knowledge of the session, and the application doesn't work. This makes troubleshooting difficult because it's often not obvious what the root cause of the problem may be.


  • Do not rely on in-memory sessions for data upon which an application relies to execute correctly. Use a database-backed session that can be shared across application or web servers or use some other mechanism for storing session-specific data necessary for the application. If you're planning on deploying in a virtual cloud environment, you have control over this. If you're planning on deploying in a platform-based cloud environment, you may not have control so ask before you begin developing so you can decide how best to proceed.
  • Use "sticky connections" or "persistence" in the networking vernacular. Ask before you begin developing applications if the load balancing service supports persistence-based load balancing. Persistence-based load balancing uses session data, usually the auto-generated session ID, to ensure that requests from clients are always sent to the same server so the session is always available. If persistence-based load balancing is available, you can leverage it and develop without concern. If it does not, you'll need to choose another option to ensure your application works as expected in that environment.
  • Use session mirroring, if available. Some solutions are capable of replicating sessions across a cluster of application or web servers. This is often accomplished by using a database, but not always. Session mirroring ensures that no matter what server the client is directed to that their session exists. Be careful of the costs associated with this solution, as session mirroring increases the amount of memory you'll need for each instance and may drive costs up if the provider charges on a memory utilization basis.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.