Rearchitecting Applications for the Cloud

Posted by Boris Lublinsky on Jul 21, 2010

Sections

Architecture & Design,

Enterprise Architecture,

Operations & Infrastructure

Topics

Cloud Computing ,

SOA ,

Architecture

 

In their SOA World article, "Cloud Application Migration", Chetan Kothari and Ashok Kumar discuss the challenges that many organizations are facing when trying to move to the cloud:

Is "cloud computing" the logical next step for me to successfully execute business strategy? If so, what should be my cloud strategy? Which applications are best suited to run on cloud? These are the questions we will discuss, attempt to answer, and where required, make suitable recommendations.

The authors of the article see many challenges migrating applications to the cloud, from "security, to SLA management, to regulations, to fear of vendor lock-in, to lack of any standards." In spite of that, they consider one should take advantage of the cloud when there is good opportunity without, necessarily trying to move everything to the cloud.

The authors encourage the transition to the cloud, noticing several benefits:

Migrating applications to the cloud to benefit from its elastic infrastructure services is a quick, cost-effective, and tactical approach to reap the benefits of the cloud. It offers a natural entry point to exploit the value of the cloud platform without any significant overhead costs. The migration will be straightforward, usually a simple re-hosting exercise, with minimal or no impact on application code. This minimizes any risks with migration while still keeping the costs low. However, it must be said that while this offers a cost-effective approach, it does not offer the cost advantage (while delivering services) against competitors who have true multi-tenant capabilities.

Their opinion is shared by ZapThink’s Jason Blumberg who considers that such a transition needs a Cloud Architecture:

The missing link between the business benefits that Cloud Computing promises and the products on the market, of course, is architecture... From the enterprise perspective... leveraging Clouds as part of the broader enterprise IT context is at the core of getting value from them. What is a best practice-based approach to leveraging Cloud-based resources in the context of the existing IT environment to address changing business needs? The answer to that question is the Cloud Architecture that is the missing link for organizations struggling to piece together a vendor-neutral Cloud strategy.

Kothari and Kumar consider materializing such an architecture a "daunting task":

Migrating applications to SaaS architecture and hosting it on a shared services model gives true multi-tenant cost advantage to an enterprise. It helps rationalize a portfolio by removing redundant applications offerings similar services across geographies or lines of business in favor of a single multi-tenant application shared across all its users. However, enabling SaaS architecture on an existing application could be a daunting task ...

The necessity of rearchitecting applications to be moved to a cloud is reemphasized by Janakiram MSV in his interview with indicthreads.com

The first step towards the Cloud is to start refactoring your applications for the loosely coupled architecture. There should not be any affinity between the web tier, application tier and the database tier. One of the key tenets of the Cloud is Elasticity, which is the ability to scale out and scale down on demand. You never know which tier of your applications demands to be scaled out. In one scenario, you may have to scale out the web tier to meet the ongoing traffic demand. If you see that the middle tier is becoming the bottleneck, you may have to add more no. of application servers and same is the case with the data tier. Given this dynamic, on-demand nature of the Cloud, your applications should be designed to seamlessly work in a single server scenario to a clustered environment.

Both Blumberg and MSV emphasize that moving to the cloud typically means that SOA and data persistence are the key elements for the cloud migration:

Respecting the SOA principles is a great step in your journey to the Cloud. The other key thing is the way data is persisted on the Cloud. There are new models like BLOBs, Queues and flexible entities...

Although everyone talks about moving to the cloud, a question rarely is brought up on which specific cloud type is more appropriate for a given company. Also, it is also not immediately clear what kind of application rearchitecting is required for a successful cloud computing implementation.

1. Back to top

   Data persistence

   by ravi varanasi

   The first step in this process is to let the services drive the persistence layer (top-down design approach). I see majority of corporate IT still stuck in the one big enterprise database model.

   Reply

2. Back to top

   Need to unlearn

   by Udayan Banerjee

   Most important step to effectively architecting for the cloud may be to "Unlearn"!
   
   Here are some pointers - setandbma.wordpress.com/2010/03/10/architectura...

   Reply

3. Back to top

   Re: Data persistence

   by Faisal Waris

   Agree. SOA is good stepping stone as it breaks the direct reliance on a relational model.
   
   SQL storage is a scalability bottleneck however it will be a challenge to move the masses from a transactional/relational mindset to cloud storage (blobs, queues & tablular storage + traditional SQL).
   
   I would have liked to see XQuery as standard data access model for the cloud but sadly that is nowhere to be seen. The next best thing may be oData (for tabular storage).

   Reply

4. Back to top

   loosely coupled architecture

   by ian green

   Original post said:
   
   "Also, it is also not immediately clear what kind of application rearchitecting is required for a successful cloud computing implementation."
   
   I think an answer in part is where Janakiram MSV mentioned the need for a more "loosely coupled architecture. "
   
   For me, so far it seems that splitting up tasks computationally is not the challenging part though, effectively handling large sets of data is the tricky part....

   Reply

• Older >