Should I migrate existing applications to the cloud

Over the last 6 months, I have increasingly seen the cloud debate moving from infrastructure to services and applications. More and more CIO’s are starting the discussion at the application level and want to know how to tackle those.

 

One question that keeps haunting me is, “Is the cloud all about transforming the way existing applications are running and experienced by the user or should cloud be focused on innovation and the support of new activities?” Ultimately, I believe it will be a combination of both. However, I think companies should thoroughly assess the added value of migrating existing applications to the cloud.

For example, if a company has spent tens-of-millions of dollars to install their ERP environment, what is the added value of moving it to the cloud? Will it reduce costs? Will it improve the agility and responsiveness of the company? Will the benefits be enough to justify the cost of that migration? I believe these are the type of questions companies need to ask themselves prior to embarking on such a journey. 

If the conclusion is positive and the decision to move the application to the cloud can be justified, one should now look at how to migrate this application to the cloud.

What does migration to the cloud really mean?

In my mind migration to the cloud means, at the very least, the user can provision an instance of the application from the service catalog automatically. This introduces the concept of service. Some applications represent one service, others many. What do I mean by that? Let's take a of couple examples. A production scheduling tool is one service. You provide it with a description of the production environment and a product demand pattern, and it delivers you a production schedule. An order entry system includes multiple services including, but not limited to, entry of a new order, order modification, order deletion, order fulfillment and order status look-up. There is not an automatic one-to-one relation between your existing applications and the services you expose in the cloud.

The first application is reasonably easy to port to a cloud environment as long as the application can run in a virtual environment. Let’s call that re-hosting the application, in other words adapting the application to run in the new environment. The application and its logic remain identical. One tricky aspect is that some databases are not supported in a virtual environment, so you may need a cloud that supports the provisioning of physical machines to host the database, while the rest of the application is hosted in virtual machines. Most cloud environments do not allow such hybrid approaches, so make don’t hesitate to ask the tough question to your cloud service provider.

The second application will need a more dramatic transformation. Ideally it needs to be transformed in a set of loosely coupled services that are called upon independently by the users through the provisioning system. The link between these services is a common data structure containing the information. There are three ways such an application can be adapted:

  1. The simplest way is often to create a series of web services, and use them to front-end the application. What I mean by that is that you interact with a small web service that in turn interacts with the application, in practice shielding you off from the intricacies of the application. Each web service invokes one function within the existing application. The web services are included in the cloud environment and all rely on the application running in a separate environment that may run in a physical, a virtual partition or in a traditional environment (hybrid delivery). This is often how legacy applications are integrated in a web environment. We integrate the application in the cloud. 
  2. If the application can be transformed in a series of loosely coupled modules that integrate through a common data structure, we basically re-architect the application and create the services that will be provisioned by the users. Each will run in a separate virtual environment, while a separate physical or virtual environment containing the common data structure is created and made visible to all appropriate services. The link between the service and the data structure is configured at provisioning time.
  3. If neither of the above works, two options remains. Either the application is not migrated and remains operated in the traditional way or the application is replaced by existing services, and then you may want to look at SaaS services as long as they support your security and compliance requirements, or rewritten.

As you can see, many different approaches exist and a long list of criteria is reviewed prior to choosing one of these approaches. Experience is critical here. And, not as many projects have been done in this area so you may want to look at SOA experts to help you in the process. I hope I did not scare you in describing the alternatives. If you already have experience, why not share it?

 

 

 

Related links:

Application transformation

Cloud computing

Service Oriented Architecture

Labels: Cloud
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.