Application Design: Going Stateless on Azure

Editor’s note: In partnership with Microsoft Press, MVPs have been contributing to an ongoing guest series on their official team blog. Today’s article is from .NET MVP Punit Ganshani and is the 52nd in the series. Thanks, Punit!

Application Design: Going Stateless on Azure


The components of a cloud application are distributed and deployed among multiple cloud resources (virtual machines) to benefit from the elastic demand driven environment.  One of the most important factor in this elastic cloud is the ability to add or remove application components and resources as and when required to fulfil scalability needs. 

However, while removing the components, this internal state or information may be lost.

That's when the application needs to segregate their internal state from an in-memory store to a persistent data store so that the scalability and reliability are assured even in case of reduction of components as well as in the case of failures.  In this article, we will understand ‘being stateless’ and will explore strategies like Database-driven State Management, and Cache driven State Management.


Being stateless


Statelessness refers to the fact that no data is preserved in the application memory itself between multiple runs of the strategy (i.e. action).  When same strategy is executed multiple times, no data from a run of strategy is carried over to another.  Statelessness allows our system to execute the first run of the strategy on a resource (say X) in cloud, the second one on another available resource (say Y, or even on X) in cloud and so on.

This doesn’t mean that applications should not have any state.  It merely means that the actions should be designed to be stateless and should be provided with the necessary context to build up the state. 

If our application has a series of such actions (say A1, A2, A3…) to be performed, each action (say A1) receives context information (say C1), executes the action and builds up the context (say C2) for next action (say A2).  However, Action A2 should not necessarily depend on Action A1 and should be able to be executed independently using context C2 available to it. 

How can we make our application stateless?


Continue reading full article here


About Punit Ganshani

Punit, based out of Singapore, is Microsoft .NET MVP and DZone MVB.  He is the author of 18 technical whitepapers published in DeveloperIQ and a book on C programming.  He has contributed to research published in the journal of American Institute of Physics.  He is an expert at Application Design & Development, Performance Optimization and defining Architecture for hybrid systems involving Microsoft, Open-Source and Messaging Platforms.  He is founder of KonfDB platform and runs a community blogging platform Codetails, organizes .NET sessions in Singapore, and has spoken in various forums in Singapore, India, London, US and Brazil.  He has developed several applications on Windows Phone and maintains his blog at  

About MVP Monday

The MVP Monday Series is created by Melissa Travers. In this series we work to provide readers with a guest post from an MVP every Monday. Melissa is a Community Program Manager, formerly known as MVP Lead, for Messaging and Collaboration (Exchange, Lync, Office 365 and SharePoint) and Microsoft Dynamics in the US. She began her career at Microsoft as an Exchange Support Engineer and has been working with the technical community in some capacity for almost a decade. In her spare time she enjoys going to the gym, shopping for handbags, watching period and fantasy dramas, and spending time with her children and miniature Dachshund. Melissa lives in North Carolina and works out of the Microsoft Charlotte office.

Comments (0)

Skip to main content