web application into the cloud - legacy applications

[A. Aka]

Hi,

I have questions regarding migrating a legacy applications (web application and 3-tier architecture) in the cloud.

When the application is being transformed to be cloud-ready, what kind of development people are doing to modernize it; I know it depends on use case but I mean in general and from your experience. are they adding caching,... ?

normally, we have many environments (dev, integration, test, staging, production), *is it interesting to put testing, staging,.. environments also in the cloud ? why ?

what are companies' strategies on this matter in general? is it only having cloud environment for production ?
If I want to have my production and staging environment in the cloud, will it cost more because it is as if I have 2 applications up running and used, right ? or is it included in the package.

Thanks,

[Jeanne Boyarsky]

A. Aka wrote:When the application is being transformed to be cloud-ready, what kind of development people are doing to modernize it; I know it depends on use case but I mean in general and from your experience. are they adding caching,... ?

The biggest change I can think of is to make sure the application runs on the infrastructure supplied by the public cloud. For example, maybe you need to be able to deploy on JBoss instead of WebLogic. Why would your application need caching in the cloud if it didn't as a standalone application? Or maybe it needed caching all along and this is an opportunity to improve it?

A. Aka wrote:many environments (dev, integration, test, staging, production), *is it interesting to put testing, staging,.. environments also in the cloud ? why ?

A big advantage of having them all in the cloud is that you know all your deployment environments are the same. Another is that you can spin up a staging instance when you need it rather than all the time.

A. Aka wrote:is it only having cloud environment for production ?

I like to have QA and Production look as similar as possible. I'd be quite wary of ONLY having Production in the cloud.

A. Aka wrote:If I want to have my production and staging environment in the cloud, will it cost more because it is as if I have 2 applications up running and used, right ? or is it included in the package.

It will likely cost more, but not twice as much. Remember you are typically charged for CPU/memory in the cloud rather than per application. In other words, you get charged by use. The exact details vary by hosting provider. Also, you are saving the money from having your own staging environment server. The cost should be compared to that rather than zero.

[Winston Gutkowski]

A. Aka wrote:what are companies' strategies on this matter in general?

There are many, some of which Jeanne has already outlined.

What you (and we) really need to know is what you mean by "the cloud". If you just mean the big, bad Internet, there are many ways to simulate that kind of environment internally without having to "go outside" until you need to, and many companies will do that with a separate (probably NAT-ted) RFC 1918 network (or networks; the 192.168 series allows you up to 256 of them) under the control of its own DNS server. That way, the connection mechanism will be very similar to the regular Internet, but you don't need to release your code into a world where crackers and viruses abound. The other advantage is that you can also simulate things like DNS, service-provider, or database outages and "dead links" whenever you like.

This is generally an infrastructure decision though, so it will usually be under the control of your admins. You, as a Java programmer (assuming that's what you are) should rarely have to worry about this sort of stuff. HTTP is HTTP, and if it works to an internal address, it should work to en external one - that's the whole reason RFC 1918 was invented - and if it doesn't, it usually indicates a problem that's beyond the scope of your Java program to handle.

On the other hand, you presumably want all your environments to use essentially the same code; and for that there are tools like dependency injection, which allow you to configure things like a "connection" or "the cloud" so that they can be supplied at runtime. Just one such tool is Guice, but there are several others.

I'm only talking about regular client/server type environments though, because it's the only thing I have experience with. For peer-to-peer or distributed systems, there are almost certainly other things to consider. I've also only ever dealt with it for IPv4; although I'm pretty darn sure v6 will have all the same "goodies" (maybe even better ones) to help you out.
All I can say is that when I was an admin for this kind of set-up, migrating to "production" wasn't anywhere near as troublesome as I suspect you may be thinking it is.

It does help to have a few friendly "beta" testers out there in Web-land though.

Winston

[Ulf Dittmer]

The "cloud" is a buzzword these days, and applied to just about everything and the kitchen sink, whether it makes sense or not. So a lot of the answers will depend on what kind of cloud software you will be targeting. Developing for SaaS (not much different from old-fashioned hosting), developing for PaaS (like GAE) and developing for IaaS (like AWS) are rather different in terms of tradeoffs for development, deployment, flexibility, pricing, convenience etc. You may want to start by reading up on these different offerings: Cloud computing.