As a Software Designer or Software Architect willing to upgrade/start a Cloud-based application you may be wondering about what are the most important design considerations to take into account. Well, one of them is behaving stateless.

The stateless behaviour is important because Cloud-Computing means for us (mere human mortals) infinitive computing resources, which is understood as scalability. Whatever platform you choose, you’ll be given the possibility to grow as much as you want, however your application need to behave stateless in order to let the underlying platform adding “transparent” new software instances to the instance pool. Adding a transparent software instance indicates that the working instances can continue working while new computing resources are being added.

Imagine one of your applications. Imagine that suddenly (while end users working on it) new virtual machines get provisioned with software instances and get ready to start processing existing request as well as new ones. Can your application afford that?

Behaving stateless means not storing/maintaining any bit of information on any storage media that can not scale out (like RAM memory, local files or registry keys). Behaving stateless it means working without context information. Although it sounds good the truth is that most applications I have reviewed behave closer to stateful.

Probably some of you have designed great blueprints, but at the development stage developers tend to start using the easiest resource they find, that’s the Session, Application or Cache object. Using the Session object is not bad, but using it being unaware of it is terrible. In fact you can use whatever storage media that allows you scale out. With that said, RAM based/machine centric objects are not encouraged to use, while database stands as the widely used option.

But don’t misunderstand the stateless pattern. Your design should rely on external persistent storage and not containing internal state. For example: Do you really need to store in Session the currently logon user? Do you think huge email services (like Gmail or Hotmail) do it? No definitely.

The big challenge is determinate when is really necessary to have context. Saving the entire user state into memory is featuritis, what you really need is to know if the user is authenticated and authorized.

So behaving stateless does not mean having no context, it do means relying on external persistent storage or using built-in platform capabilities to avoid having internal state and being able to reconstruct the entire processing chain with little or no context information. For example: if you are building an ASP.Net MVC Razor application then within each Controller you should instance your objects based on the current logon user:

        protected override void Initialize(System.Web.Routing.RequestContext requestContext)
        {
            concreteFacade = new ConcreteFacade(System.Web.HttpContext.Current.User.Identity.Name);
            base.Initialize(requestContext);
        }

That’s all what you need to know. Forget about the entire user object, forget about loading permissions, any piece of software within your design should be able to get instanced and working with little-platform based information.

Cheers,

Javier Andrés Cáceres Alvis

Microsoft Most Valuable Professional – MVP
Intel Black Belt Software Developer