"Now comes the hidden question: how would you profile your j2ee app to determine if it is a candidate to cloud or not; knowing that it is"

As an aside, make that the Explicit question. Make it the TITLE of this question. Put it in the beginning of the question. If possible, delete all of your assumptions, and focus on the question.

Here s what we do.

1. Call some vendors for your "cloud" or "managed service" arrangement. Not too many. One or two of each.

2. Ask them what they support. More importantly, what they don t support.

3. Then, given a short list of features that aren t supported, look at your code for those features. If they don t support things you need, you have some architecture work to do. Or cross them off your preferred vendor list.

4. For good vendors, write a pilot contract that gives you free (or cheap) access for a few months to install and test. If it doesn t work, you haven t paid much.

"But why go through the expense of trying to host it when it may not work?"

What expense? You can spend months "studying" your code. Or you can try to host it. Usually, the "try to host it" will turn up an answer within a few days. It s less effort to just do it.

What sort of Cloud Service are you talking about? IaaS, PaaS, DaaS ?

architectural change (you might not install anything you want)

Depends: moving from a "managed server" to a Platform (e.g. GAE) might be.

learning curve (because of the above)

Amazon EC2 might not be a big learning curve if you are used to running your own server

no failover (since failure is taken care of)

Depends: EC2 -> you have to roll your own

instantaneous scalability (not so instantaneous, but at least transparent?) ? lower latency Depends: EC2 -> you have to plan for this / use an adjunct service

There are numerous cloud providers and as far as I ve seen there are two main types of them:

• Ones that support a cloud computing platform (e.g. Amazon E2C, MS Azure)
• Virtual instance providers providing you ability to create numerous running instances (e.g. RightScale)

As far as the platforms, be aware that relational database support is still quite poor and the learning curve is quite long.

As for virtual instance providers the learning curve is really little (you just have to fire up your instances), but instances need some way of synchronizing... for a complex application this might not work.

As for your original question: I don t think there s any standard way you could profile wether an application should / could be moved to the cloud. You probably need to familiarize yourself with the options, narrow down to a few providers and see if the benefits you would get to them would be of any significant win over managed hosting (which you re probably currently doing).

In some ways comparing google app engine (gae) and amazon ec2 is like comparing apples and oranges.

With ec2 you get an operating system, with or without installed server software (tomcat, database, etc.; your choice, depending on which ami you choose). With ec2 you need a (or be a) system administrator to keep things running smoothly. Load balancing on ec2 is something you ll have to figure out and implement; I ve never done that part. The big advantage with ec2 is that you can spin up and down new instances programatically, and compared to a regular web server provider, only pay for when your instance is up and running. You use this "auto spin up/down" to implement your load balancing and failover. But you have to do the implementation (again, I have no experience with this part).

With google app engine (gae), all of the system administration is taken care of for you. It also automatically scales out as needed, both on the app side and the database side. You also only pay for what you use; an idle app that gets no hits incurs no costs. The downsides to gae are that you re restricted in the languages you can use; python and java (or things that run on the jvm, like jruby). An even bigger downside is that the database is not sql (they don t call it a database; they call it the datastore) and will likely require reworking your ddl if you have an existing database; it s a definite cost in programmer time to understand how it works and how to use it effectively.

So if you re starting from scratch (or willing to rewrite) and you have the resources and time to learn its ways, gae may be the way to go. If you have a sysadmin or sysadmin skills and have the time or know how to set up load balancing and failover then ec2 could be the way to go. If your app is going to be idle a lot then ec2 is expensive; last time I checked it was something like $70 a month to leave a small instance up.

I think the points you have to focus are:

 granular cost (pay per Ghz or Gbyte)
 instantaneous scalability (not so instantaneous, but at least transparent?) ? lower latency

Changing your application to run on a cloud will take a good amount of time, but it will not really matter if the cloud don t lower your costs and/or you don t really need instantaneous/fast scalability (the classic example are eCommerce app)

After considering these 2 points. The one IMO you should think about is relies on a complex database (ie. num. tables), since depending on its "conplexity", changing to a cloud environment can be really troublesome.