From the Founder & VP Products at CloudSwitch

Ellen Rubin

Subscribe to Ellen Rubin: eMailAlertsEmail Alerts
Get Ellen Rubin: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Among both users and industry professionals, there is no shortage of discussion about mapping application types to the different cloud domains (public, private, hybrid, etc.). In my experience, quite a bit of this discussion centers on breaking down the characteristics and traits of the application (what kind of data does it deal with, where are the external components it connects to, what are the throughput demands, etc.), and mapping those to a distinct cloud domain

I believe that this way of mapping applications to cloud domains overlooks a simple fact: applications have lifecycles. Most of the time organizations map application characteristics to a cloud domain, they do so with the application's production requirements in mind.  This overlooks the development, testing, staging, and probably a host of other phases in the application's journey toward production readiness, and in some cases, it may be best to use different types of cloud environments along this journey.

Consider the case that an IT organization has decided to begin leveraging cloud computing techniques both within their own data center and from the public cloud. For a particular application (maybe an accounts management application), they decide it is best suited for the private cloud due to concerns over the sensitive nature of the data with which it interacts (I'm not endorsing private over public or vice versa, just posing a scenario and decision-making process that is not all that uncommon).

In all likelihood, the decision to use a private cloud for the organization's account management application is indicative of the application's production-level requirements. However, does this necessarily mean the application cannot benefit from a public cloud environment as it moves along to production? Nope.

In a fair number of cases where applications deal with sensitive data, they really only do so in their production environments. During the development and testing process, the application interacts with mock data. The data has the same structure, but the contents are not confidential. If the sensitive nature of the data used by the application was the chief reason  for choosing the private cloud, acknowledging the fact that such data is really only sensitive in a production environments opens the door to the possibility of using a public cloud during the development and test process.

Simply put, one should consider the characteristics of an application and put those characteristics in the context of each phase of the application's lifecycle in order to understand how the application can make use of the cloud. Throughout this process, there are important factors to keep in mind. If you do in fact plan to leverage multiple domains in the delivery of an application, how easy will it be to move the application from one domain to the next? Will your application use the same platforms in the different domains? Can you automate the migration of the application from one lifecycle phase to the next? Can you capture an environment and easily reproduce it in a different cloud domain?

This is a small sample of the kinds of questions one should consider if they plan to leverage multiple cloud domains for a single application. While leveraging multiple domains during the lifecycle of an application may seem to make things more complicated, keep in mind that it can bring substantial benefits. It may mean decreasing the cost of developing and delivering applications, decreasing the time to market, or even enhancing support capabilities of an application already in production. Simply put, do not fall into the trap of making a one-to-one mapping between an application and its cloud domain. Consider the application's lifecycle and construct a plan for using the cloud.

More Stories By Dustin Amrhein

Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, he worked on the development of Web services infrastructure and Web services programming models. In his current role, Dustin is a technical specialist for cloud, mobile, and data grid technology in IBM's WebSphere portfolio. He blogs at You can follow him on Twitter at