In many cases the industry talks about cloud computing being a new and optimized approach to delivering IT services. From the point of view of application developers, cloud computing offers dynamic platforms that equip them with the capability to deliver their application in an on-demand fashion. Applications running on a cloud platform scale up and down to meet the needs of its users. So, in the face of this new delivery model for applications, should application architects and developers expect this to have an impact on application architecture and design?

There are indeed considerations one should make for any application they are considering porting to the cloud or developing for the cloud. In some cases, these considerations are the same ones that should be made for applications running in a traditional environment, but in the case of a cloud environment they have additional importance. In other cases they are specific to cloud environments. I'll offer up three that come to my mind when thinking about this approach.

Cloud Expo New York to present 5,000 delegates and more than 100 exhibitors at the Jacob Javits Convention Center in New York City

1)      Loosely-coupled component architecture: The business application should be made up of discrete components (business logic, data, mediations, etc.) that are loosely-coupled. While this is good practice for any application architecture (after all it's a fundamental principle of SOA), in the cloud this has new significance. By delivering the application in discrete, loosely-coupled components, this means that users can apply policies to each of those components that allow them to scale independently of the others. For instance, if the bottleneck in an application is data access, as long as it was loosely coupled the data components could be scaled up to meet the demand without having to scale up (and consequently pay for) the entire solution.

2)      Use of in-memory data grids: Speaking of data, almost all applications deal with accessing data from some external source.  In many cases the external source is a database, and for quite a few applications databases become a bottleneck. For an elastic application, when demand spikes one can attempt to scale up databases, but this is not typically cheap or sustainable due to their resource-intensive nature. Another way to solve the need to scale up data is the use of in-memory data grids. With this approach, data can be offloaded from the database into memory processes, and scaling becomes as easy as starting another process (i.e. Java Virtual Machine). There are considerations when using in-memory data grids such as the toleration of sometimes stale data, the degree to which your data can be partitioned and more, but it is definitely an approach worth considering.

3)      Isolation of environmental dependencies: In most of the cloud platform solutions on the market today, cloud-based applications will be running inside of some type of virtual machine. For each requested deployment these virtual machines are activated by the cloud platform, and during activation information particular to the environment that was just created is passed to the machine. This includes information like the IP address, host name, and various other bits that will change each time an environment is created. Applications must not have a hard-coded dependency on any information that could change each time one of these machines is activated. Instead, there should be an isolated mechanism for the application to retrieve or otherwise be made aware of this environmental information.

Certainly this is nowhere near an exhaustive list of considerations for cloud-based application development. These are however, three that I think are fairly significant and getting them right can deliver some pretty big advantages. What considerations have I missed? I'd be very interested to hear other takes on this topic, so send me a tweet at @WebSphereClouds.