How to reduce the risk in developing applications in Windows Azure

Windows Azure is a new platform. Thus many decision makers think that developing application on Windows Azure is too risky. In this post I would like to challenge that.

Windows Azure is an operating for the cloud. It means that Windows Azure deals with abstracting the cloud to your application and storing data in Microsoft's data centers. It has nothing to do with the application itself.

From the application point of view I would like to argue that the application should never know on which platform it is being hosted and who exactly stores its data.

I love Domain Driven Design (DDD). Classes are grouped in domains. An abject does not "know" any other object outside its own domain. Cross domain calls are implemented using interfaces. For example if an "Employee" needs to store some data it calls the nearest IDataStorage implementation. It has no knowledge who exactly is the implementation it is using and it does not care. The IDataStorage knows to store the data. That is all that matters.

When developing Azure applications such abstractions should be used. Behind the abstraction there can be Windows Azure implementations for Azure installations (for example Azure Storage) or on premises implementations such as SQL for traditional installations. An Azure implementation of a Data Access Layer (DAL) must be implemented with deep knowledge of the mechanics of Azure storage services but users of such DAL do not need to know anything about it.

Yet there is one rule that must be enforced throughout the application: Make it stateless.

It means that the core application code should not save state (data that is used between several calls) directly in memory or in the file system. State must be stored by using an abstraction of a state manager. In single instance installations the state manager can use the memory or the file system but in distributed installations (such as Windows Azure) the state manager must store the data in a single location that all instances can reach. Examples can be a distributed cache, Azure storage or a database.

If you write applications that do not abstract their interfaces with Windows Azure the development cycle will be longer because most developers will have to install Azure development SDK and be familiar with the technology. Testing will be more complicated because it is dependent on Windows Azure and it has to test scenarios where the compute and storage emulators do not behave like the real cloud. (There are many)
The outcome is simple: The overall software development risk is high.  

If you keep the stateless rule and you abstract all infrastructures (DDD) you can develop applications and have the freedom to decide where to host it. You can use the cloud; you can use a local data center; you can do a hybrid installation.  Testing is simple because you are not bound to a particular environment also the development speed is higher because most developers do not need to install anything and know about Azure.
The outcome is simple: The overall software development risk is low.

Azure is not that special. All good software abstracts the infrastructure they use. All distributed systems are designed to be stateless and keep their state in an independent state manager accessible to all instances. It means that if you design your software properly the fact that you want to host it in Windows Azure does not introduce a substantial additional much risk.

Manu