Definitions

Cloud-Burstable Applications are those built using an application deployment model in which an application runs in a private cloud or corporate data center and bursts into a public cloud (or clouds)  when the demand for computing or storage capacity spikes.

Cloud-Portable Applications are applications that can take advantage of multiple clouds in order t0 prevent lock-in and/or make the applications more resilient in the face of cloud outages.

Motivation

It should be pretty clear why we want to build applications that are Cloud-Burstable. It would be a great advantage to be able to overflow our resource requirements into the cloud (or clouds). The advantage of this is that the company only has to pay for for extra compute and storage resources when they are needed.

Cloud-Portable applications, on the other hand, make you less vulnerable to cloud outages as both Amazon Web Services (AWS) and Windows Azure users have experienced recently.

Another benefit of Cloud-Portability is to remove the fear of cloud vendor lock-in. It is always nice to feel that you can take your business elsewhere even if you never do.

Architecture

Just because we have moved to the cloud does not mean that we should automatically abandon all the good architectural design techniques and design patterns that we have been using successfully in developing on-premise applications. Designing an application that segregates functionality into layers (such as Presentation, Business Logic and Data Access) can go a long way to making an application more portable.

If we examine the typical business application we will probably find that the bulk of the application exists in the Business Logic Layer. In the case of the Data Access Layer in particular the differences in the APIs supported by a particular vendor’s offering can be hidden from higher level layers of the application. (Encapsulating an area of an application that is subject to change is a proven architectural technique.)

Lets limit our discussion to on-premise applications running in your data center and the two most popular public clouds; Amazon Web Services and Windows Azure. We also limit our discussion to .NET web applications, however, in principle the same approached should be applicable to other public and private clouds. 

IMO there are good ways to achieve Cloud-Bursting between an on-premise data center and the Azure and/or Amazon clouds .  The following assumes a well architected application that is built using a three-tier model.(And yes I know what “assume” means ,  but it should be more or less true for most applications.)

Anyway, lets attack the architecture layer by layer.

Presentation Layer

The Presentation layer of a .NET web app is primarily an ASP.NET application so, if the application is of the type that was originally (or newly) written to run in a web farm environment with externalized application state then not much is required to make it portable.  If it uses SQL Server in its Data Layer then compatibility is very high anyway. (If not, see below.)

Windows Azure runs ASP.NET applications that are so architected.  Some minor encapsulation might be required to support this, but it should be minimal.

AWS does too, by virtue of the fact that it is Infrastructure as a Service (IaaS) and fully supports Windows, IIS, .NET and .NET applications.  If it runs on premise then it can be hoisted up onto AWS without too much difficulty.   (Ignoring considerations caused by physical separation, such as latency.)

Business Layer

If Business rules are encapsulated in a separate Business Layer then this layer should be more-or-less totally platform independent. There may be a need for some encapsulation if the business layer makes any direct API calls to other services. It shouldn’t as a rule. So it should be the most portable of all.

Data Layer

Here is where the major differences between on-premise, Azure and Amazon exist.  Encapsulation can be used to add a level of abstraction between:
• Blob storage services (AWS Simple Storage Service and Windows Azure Blob Storage)
• NoSQL storage (AWS Simple DB/DynamoDB and Windows Azure Table Storage)
• Relational database (AWS Relational Data Service and SQL Azure)

In the above discussion I have not included the on-premise equivalents of storage APIs such as those provided by the Windows file system, SQL Server etc. but the approach should be easily extendable.

Other APIs could be suitably encapsulated and made platform independent where they exist.  And techniques like Dependency Injection and Factory Patterns could be used to select the appropriate interface modules at execution time based upon configuration or convention.

Conclusion

I realize that this smacks of “SMOP” (Simple Matter of Programming), and that the devil is in the details, but it should be a workable strategy. Of course it all depends on whether we are talking about a greenfield app or one that already exists, and whether it is well-written using a three-tier model or not.

What do you think?

Bill Zack