To Move or Not to Move

Many enterprises out there are at a point in time when they are making a very important decision regarding their enterprise applications: To move or not to move. Of course, I'm talking about the decision of moving applications to a cloud computing environment or continuing to deploy in more traditional environments. The question is not easy, and many times enterprises should answer it on an application-by-application basis, taking time to thoroughly assess each situation.

Many factors come in to play with respect to whether or not an application is a good fit for the cloud:

- Is the application dependent on a particular type of underlying infrastructure or operating system?

- Does the application interact with data that, in your assessment, is not suitable for a public cloud?

- Is the application tightly coupled to other components that cannot be moved to the cloud?

- Will the application benefit from quick provisioning and elasticity?

I could go on and on here, but the idea is there are numerous points of consideration that go into making such a decision. One such decision point, and one not listed above, is what sort of application changes will be necessary for such a migration. As I see it, the answer to this question largely depends on the type of cloud service you are looking to consume. Specifically, the probability that changes are necessary will vary based on whether your are pursuing cloud solutions geared toward infrastructure services versus those geared toward platform services.

Consider the case of a pretty standard Java middleware application. The application runs with a standard application container and interacts with a backend database as part of its transactional duties. If you were to take to this application, and move it to the cloud using an infrastructure services solution, there is a strong likelihood that little to no changes would be necessary. This is because cloud infrastructure services are at least one layer below the application.

These types of cloud solutions focus on abstracting the underlying infrastructure, and in the context of Java middleware applications, making it fast and simple to deploy the underlying middleware infrastructure. In other words, you can simply request an instance of the application container and the database, and in minutes, you will have it out there and running. Once that infrastructure is up and running, you deploy your application. There is probably no reason to change anything, because in the end, it is the same application container and database. It just so happens that those components are running on a cloud-based infrastructure.

Now consider deploying such an application on a cloud solution that provides platform services. The circumstances change quite a bit, because now the unit of work is the application instead of the infrastructure. You interact with the platform service to describe the application and its requirements, and the cloud is responsible for rendering the underlying infrastructure. This puts the onus on you, the application owner, to consider the types of dependencies present in your application. For instance, using our simple example above, we would need to consider questions such as:

- Is the application tightly coupled to the application container, or is it standardized in its components and API usage?

- Is the application tightly coupled to a particular database?

- Can the application tolerate shared services or does it require a single tenant approach to the underlying infrastructure?

- Did you design the application to tolerate independently scaling components?

There are many, many more questions to consider, and they will of course vary according to the specific cloud platform service you are using. However, the point I mean to bring out is that the probability that your application will require change is typically higher when using platform services versus using infrastructure services.

My intention here is certainly not to say that platform services are problematic to adopt because they will require application change. It is not the case that all applications will require changes to make use of this type of cloud service and in cases where it does, well change is not always a bad thing. It depends on the benefits that you get from making the change. My intention with this discussion is to point out that deciding which applications to move to the cloud is a tricky proposition and one that depends on many factors. I'm keen to follow the evolution of both infrastructure and platform services and the way they affect both application design and implementation.

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 http://dustinamrhein.ulitzer.com. You can follow him on Twitter at http://twitter.com/damrhein.