That is the question. Right now a lot of companies are struggling with the decision as to how (or if) to take advantage of public Cloud technologies such as those provided by Windows Azure, Amazon Web Services and other public Cloud platforms. Clearly there are advantages to be achieved by appropriate use of these technologies, however it is not totally clear as to what applications (or parts of applications) can and should be moved to the Cloud.  On one hand there can be great cost and scalability advantages. On the other hand there are questions of security and Internet latency to be dealt with. So the question is: What applications (if any) can and should I take to the Cloud? And what are the decision criteria for when and how to do it?

A lot has been written both pro-and-con about the Cloud lately. In fact so much that it can be very confusing for a first time potential user.  In order to help you making the decision I have provide a modest flowchart-based decision process for deciding when and how to move applications to the Cloud. (Note If you are not familiar with Cloud terminology please refer to the publication: NIST SP 800-145, The NIST Definition of Cloud Computing for an excellent introduction.It is important to understand that terminology because there is a lot of hype surrounding any new technology such as the Cloud.)

(There are a couple of fun expressions in Net-Speak: IMHO (In my humble opinion) and IMNSHO (In my not so humble opinion. What I am putting forth in this series of blog posts falls into one (or both) of those categories. ) 

You should also be aware that this flowchart covers the considerations at a fairly high level and that there are a lot of sub-decisions that you will have to take into consideration when making your choices. Hopefully, however, this will give you a good start on a process.

Since this will be a series of blog posts discussing various decision points in the flow you can also play along and try to infer what I am about to say about the flowchart in future posts.

Although a similar decision methodology could be produced for any public (or for that matter private) Cloud platform this one will be based on Windows Azure. Although I have architected and built applications based on Amazon Web Services as well as Windows Azure, Windows Azure is the platform that I know best having been a Windows Azure Subject Matter expert while at Microsoft.

The following flowchart is a high level mapping of the decision process that one could go through in making decisions and executing your Cloud strategy.

Select an application from your portfolio

The first task before us is deciding which application to move to the Cloud. This could be an existing application or one that hasn’t even been developed yet. First we need to determine if it is “fit” for the Cloud. This is very important because , although there are significant cost and other advantages to leveraging the Cloud it is also possible that choosing the wrong application could be more expensive for you in the long run.

Is it Fit for the Cloud?

There are several typical workload patterns that lend themselves well to a Cloud solution. These workload types have been well documented by Microsoft, Amazon and others.

On and Off workloads

You have batch job processing which might be required to be run at periodic intervals.  The capacity required to support running the job might be needed only during those intervals and be wasted for the rest of the time. Why pay for idle capacity that you are not using?

Workload that is Growing Fast.

You may have an idea which could turn out to be the next Facebook. Or it could be an idea whose time has not yet come. There is no way to know whether it will be successful or not. Why acquire the hardware capacity necessary to support you application at scale when you can contract for resources on a pay-as-you go basis and scale them up or down as required.

Unpredictable Bursting:

With this type of workload you may suddenly find yourself “discovered” by the world and need to scale up to meet the sudden demand. An increase in demand could also cause a decrease in performance if you cannot scale up quickly.  On the other hand, if the peak demand is not sustained over a long period of time then scaling down might be just as important as scaling up.

Predictable Bursting

With predictable bursting we have the type of workload that is subject to periodic peaks and valleys. It could be an ecommerce site that is hit hard during the Christmas season and less so during other months. Or the periodicity could be on a monthly, weekly or even daily basis.

What if none of these patterns fit?

Even if the application does not fit these characteristics it may still be appropriate to take advantage of the Cloud by implementing a Hybrid combined Cloud/On Premises solution. My friend Bill Wilder who is a Windows Azure MVP in Boston and the author of the excellent Cloud Architecture Patterns book has suggested that my decision methodology could still be applied to each layer/tier of an application architecture. That could be appropriate where, for instance, some parts of an application may not be able to be moved into the Cloud because of security, regulatory or other reasons. It is possible that some parts of the application may have to remain safely behind the firewall while other parts can still take advantage of the Cloud.

Implementing a new application?

Assuming that you have decided that the application under consideration is one that should be moved to the Cloud the first major decision that you are faced with is whether it is a new application that can take full advantage of the Cloud or an existing application that my or may not be easy to move to the Cloud.

Even for a new application that has not yet been written there are three choices to make.

1. If the application is fit for a Software as a Service (SaaS) solution and there exists a commercial service that can satisfy the requirement then simply contact for the service. That is the simplest approach because you have no development to do and no infrastructure components to maintain. The service provider does it all.

2. If the application is not amenable to a SaaS solution then the next thing to consider is whether it is appropriate to develop it using the Platform as a Service (PaaS) services provided by your favorite Cloud provider, in our case Windows Azure.

3. Finally, if none of those approaches are appropriate then you can always implement it using the Infrastructure as a Service (IaaS) capabilities of the Cloud provider.  Since you can do pretty much everything that you can do on premises in the Cloud using IaaS that can be your final and all inclusive choice.  (Note: Obviously that is a bit of an over simplification since there are other factors introduced, both positive and negative, by implementing an application in the Cloud vs. on premises.  For instance, latency over the internet is usually a negative factor and the high degree of scalability available in the Cloud vs. on-premises is a positive factor. But as a first level approximation it is  good start.)

(Note: If you are not familiar with Cloud terms such as PaaS, SaaS, IaaS please refer to the NIST publication referenced above for an excellent introduction. It also covers many of the Cloud-related terms that you will come across when dealing with the Cloud.)

What about an existing application?

Now the fun begins, because there are a lot of decisions to make and a lot of design points to consider. While you are waiting for the next post in this series here is some homework. Take a look at the rest of the flowchart and try to anticipate what we will be covering.

(To be continued next week)

Bill Zack