cloud hosting vs. managed hosting

Question

Hi all,

It seems the hype about cloud computing cannot be avoided, but the actual transition to that new platform is subject to many discussions...

From a Theoretical viewpoint, the following can be said:

Cloud:

• architectural change (you might not install anything you want)
• learning curve (because of the above)
• no failover (since failure is taken care of)
• granular cost (pay per Ghz or Gbyte)
• instantaneous scalability (not so instantaneous, but at least transparent?) ? lower latency

Managed:

• failover (depends on provider)
• manual scalability (requires maintenance)
• static cost (you pay the package , whether you use it fully or not)
• lower cost (for entry- packages only)
• data ownership ( you do )
• liberty ( you do ) ? lower latency ( depends on provider)

Assuming the above is correct or not; Nevertheless, a logical position is "it depends.." .. on the application itself. 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

• a quite big app in number of services/ functions (i.e.; servlets)
• relies on a complex database (ie. num. tables)
• doesn't need much media resources, mostly text based

Answer 1

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

Answer 2

"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 the 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.

Answer 3

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).

Answer 4

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.

Answer 5

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.