See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/264937852

Architectural Options for Cloud Migration

Article  in  Computer · August 2014

DOI: 10.1109/MC.2014.203

CITATIONS READS
11 827

1 author:

Nabor C. Mendonça
Universidade de Fortaleza
85 PUBLICATIONS   637 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Cloud Computing View project

All content following this page was uploaded by Nabor C. Mendonça on 28 August 2014.

The user has requested enhancement of the downloaded file.

Note: This is the author’s accepted version of the paper, without the final editing by the publisher. The final version is available
online in the IEEE Computer Society Digital Library (DOI: http://dx.doi.org/10.1109/MC.2014.203).

Cloud Cover
Architectural Options for Cloud Migration
Nabor C. Mendonça
University of Fortaleza

Identifying and examining potential cloud migration constraints and adopting a

suitable architectural solution are important steps to facilitate successful
application migration to the cloud.

As cloud computing rapidly becomes the IT industry’s “new normal,”1 organizations considering whether to adopt
this computing paradigm must evaluate several sometimes conflicting factors, both technical (migration effort,
environmental constraints, performance impact) and nontechnical (security risks, operational costs, business gain).
Cloud adoption poses particular challenges for organizations whose businesses depend on legacy applications—
some of which may rely on programming languages, system libraries, and execution environments that aren’t fully
supported by or readily available in the cloud. Developers need to anticipate possible hurdles to cloud migration and
come up with architectural solutions that circumvent them.2

Cloud Migration Strategies

A typical software application contains several independently deployable components—client front end, application
server, database server, and so on. Each component interacts with its own underlying execution environment and
possibly with other components or another application’s components through services with well-defined interfaces.
After cloud migration, a component must be able to resolve its external service interaction dependencies from within
cloud boundaries in order to operate correctly.
However, technical incompatibilities between the components’ original operational environment and the cloud
operational environment may make this impossible. Consequently, application developers might need to adapt or
change affected components so that they comply with the cloud’s operational requirements. Moreover, taking full
advantage of inherent cloud benefits, such as elasticity and high scalability, might require developers to further
modify application components hosted in the cloud. An alternate strategy simply uses existing cloud services that
offer similar or related functionality. The challenge, here, is making sure that affected components can effectively
access the new services in the cloud.
We distinguish these two migration strategies—hosting potentially modified application components in the cloud
or replacing them with appropriate cloud services—as cloud hosting and cloudification. These strategies represent
the spectrum of cloud migration alternatives now being studied in both academia3 and industry.4 Figure 1 illustrates
both strategies using a simplified UML notation, and presents some specific architectural solutions developers could
use to implement them. Table 1 summarizes the migration context and usage scenario for the two cloud migration
strategies as well as the specific architectural solutions discussed here.

Cloud Hosting
Developers’ decisions regarding architectural solutions to properly host a given application component in the cloud
depend on the constraints the provider may impose on the cloud’s operational environment, and on how those
constraints affect the target software component’s deployment and execution.
Several commonly employed solutions stand out.

Rebinding
 The simplest way to deploy an application component in the cloud is by rebinding. Here, the developer’s only
concern is making sure the target component can restore its state and properly re-establish all its external service
 ...
!
Figure 1. Two migration strategies, cloud hosting and cloudification. The different possible
architectural solutions are illustrated for each case.

dependencies after migration.

This solution is predicated on two main conditions: the target component’s original operational requirements
must be fully compatible with the operational environment available in the cloud, and the cloud must not restrict any
of the service types the component uses to interact with other external components.
A sample scenario appropriate for this solution is migrating a Java Enterprise Edition (JEE) application to
JEEcontainer running in a public infrastructure as a service (IaaS) cloud such as Amazon EC2
(http://aws.amazon.com/ec2).

Service adaptation
Service   adaptation   is   recommended   for   cloud-­‐hosting   scenarios   in   which   the   cloud   can   prevent   the   target  
component  from  communicating  with  other  external  components—including  its  users—through  a  particular  
service  type.    
To implement this solution, developers need to deploy two additional components: one in the cloud, at the side of
the target component, and one at the side of the external component with which the target component needs to
communicate. These two components act as service adapters, allowing the target component and the external
component to communicate indirectly across the cloud boundaries.
 A sample scenario implementing this solution involves migrating a legacy desktop application to a public IaaS
cloud. Enabling remote access to the application’s GUI in the cloud requires a virtual desktop service, such as
Amazon WorkSpaces (http://aws.amazon.com/workspaces). Here, the Web browser, at the user side, and the virtual
desktop service, at the cloud side, act as the two adapters.

Service conversion
Service conversion offers a more flexible, albeit more intrusive, alternative to service adaption. Instead of using
adapters to allow the target component to communicate with some external component outside the cloud, the
developer actively implements the required service adaptation by converting the two affected components to use a
new cloud-compliant communication service.
A sample scenario for this solution is migrating a file-based batch processing application to an IaaS cloud. Here,
the developer must first convert the batch application into a fully fledged Web service, and then convert other legacy
components that previously communicated with the batch application so they can remotely invoke the new Web
service in the cloud.

Compensation
If   there’s   no   practical   way   to   allow   the   target   component   to   communicate   with   other   external   components  
outside   the   cloud,   a   possible   alternative   is   to   alter   the   target   component   so   that,   after   migration,   it   can  
somehow  “compensate”  for  the  missing  components.  The  target  component  may  be  altered  in  two  ways:  the  
developer   either   disables   the   functionalities   the   target   component   previously   required   from   the   other  
components,   or   the   developer   incorporates   those   same   functionalities   as   though   they   were   part   of   the  
component’s  original  implementation.    
In addition to requiring greater development effort, both cases may result in critical consequences that must be
carefully assessed. For instance, disabling a crucial functionality may disrupt or seriously compromise the
component’s operation in the cloud; incorporating any nontrivial functionality may impact some of the component’s
quality attributes, such as performance and scalability. Still, some compensating alteration might be the only
solution.
A sample scenario requiring such a compensation solution involves migrating a multithread Java application to a
platform-as-a-service (PaaS) cloud such as Google App Engine (https://cloud.google.com/products/app-engine),
where thread creation is usually restricted or even prohibited. In this scenario, the application’s multithread features
would have to be properly disabled without compromising operation or re-implemented using the cloud’s own
thread API prior to the application’s migration to the cloud.

Cloudification
Replacing one or more application components with existing cloud services that offer similar or related functionality
has two main requirements: there must be candidate cloud services to replace each of the target components, and the
target components’ current state must be transferable to compose the state of the corresponding services in the
cloud.
Cloudification usually involves one of the following architectural solutions.

Replacement
Like rebinding for cloud hosting, replacement is the simplest form of cloudification. But this solution is only feasible
if the target component and the candidate cloud service have identical or fully compatible interfaces. Assuming this
fairly stringent requirement, a developer can perform the replacement by first transferring the state of the target
component to the cloud, and then reconfiguring the application so that the affected components can access the
candidate service in the cloud (rather than accessing the original target component).
A typical scenario for this solution involves replacing an in-house relational database with a cloud-based
relational data service, such as Amazon RDS (http://aws.amazon.com/rds).

Interface adaptation
If the target component and the candidate cloud service have functionally related but incompatible interfaces, one
useful solution is to reconfigure the other components to access the cloud service through an adapter, thus avoiding
the need to change the affected components directly. The requirement in this case is that the candidate cloud
service’s interface must be adaptable to that of the target component. As the corresponding diagram in Figure 1
shows, the adapter may be located either inside or outside the cloud.
A sample scenario for this architectural solution is implementing a customized local file system driver that
automatically redirects all local disk access to equivalent operations of a cloud-based storage service, such as
Amazon S3 (http://aws.amazon.com/rds). Here, the customized driver acts as a local adapter via which existing
application components can access the storage service in the cloud as if it were the local file system. Dropbox’s
desktop client application can be used in a fairly similar fashion (https://www.dropbox.com/help/65/en).

Interface conversion
Like interface adaption, interface conversion addresses the need to replace the target component with a candidate
cloud service that has a related but incompatible interface. However, instead of using an adapter the developer here
actively implements the required interface adaptation directly in the source code of each affected component,
thereby converting them so they can access the candidate cloud service through its native interface.
In this scenario, all existing application components pertinent to the migration must be individually converted in
order to access the candidate service in the cloud.
 
Table 1. Recommended strategies and solutions for cloud migration.

Migration context Strategy Solution Example scenario

The target component is fully com- Cloud hosting Rebinding Migrating a JEE application to a JEE
patible with the cloud’s operational container running in a public IaaS cloud
environment.
One or more of the target component’s Cloud hosting Service Migrating a desktop application to a
external service dependencies are adaptation public IaaS cloud with users remotely
incompatible with yet can be adapted to accessing the application’s GUI through
operate in the cloud. a Web-based virtual desktop service
One or more of the target component’s Cloud hosting Service Converting a file-based batch
external service dependencies are conversion application into a fully fledged Web
incompatible with yet can be converted service so as to allow its migration to a
to operate in the cloud. public IaaS cloud
One or more of the target component’s Cloud hosting Compensation Disabling or re-implementing thread
external service dependencies are creation features in a multithread Java
irreconcilable with the cloud. application so as to allow its migration
to a public PaaS cloud
The state of the target component is Cloudification Replacement Replacing a local relational database
transferrable to the cloud, and there is a server with a cloud-based relational
candidate cloud service with a fully data service
compatible interface.
The state of the target component is Cloudification Interface Using a customized file system driver
transferrable to the cloud, and there is a adaptation to redirect all local disk access to a
candidate cloud service with an cloud-based file storage service
incompatible yet adaptable interface.
The state of the target component is Cloudification Interface Converting a file-based application so
transferrable to the cloud, and there is a conversion that it can access a cloud-based storage
candidate cloud service with an service
incompatible yet convertible interface.
 
   
Other Migration Considerations
Identifying the most suitable architectural solution for a given cloud migration scenario must also take into account
other potential variables related to the overall process. The migration effort required should be estimated along with
its potential impact on the application’s quality attributes. Candidate components for migration must be evaluated
and selected. And, finally, the possibility of combining different migration strategies and deployment models should
be considered.

Effort and quality impact estimation

Reusing independently deployable service adapters as part of a migration solution avoids the need for modifying
existing application components to conform with a particular service type, thus reducing the overall migration effort.
Another advantage of using adapters is that they can be a handy way to provide application components with other
complementary services, such as data encryption and compression, which also contributes to improving the
application’s quality attributes.
On the other hand, having multiple adapters acting as intermediaries between local and cloud-based application
components and services can impose significant performance overhead.

Component selection
Choosing  which  application components one should host in the cloud or replace with an appropriate cloud service is
crucial, and the decision can affect the entire migration process. For instance, cloud hosting only a subset of
application components requires less effort than migrating the whole application stack to the cloud—but it might
also incur a higher communication overhead if the components inside and outside the cloud are too tightly coupled
or have a high data exchanger rate.

Hybrid strategies
No single migration strategy is likely to meet all an organization’s technical and business needs. Therefore,
organizations should expect to use a combination of architectural solutions and deployment models as part of their
cloud migration decisions.
For example, an organization might decide to host all application components with strong security requirements
in its own private cloud, and only to cloudify, via a public cloud provider, components with high scalability
requirements that aren’t so security sensitive. Another organization might follow a more gradual migration strategy,
in which developers first host the target application components in a private cloud and then start to cloudify one
component at a time as they gain more confidence with the public cloud’s operational model.

Cloud migration is a nontrivial process that touches many facets of an organization, from general business needs to
more technical decisions about appropriate software architectures and tools. Understanding common migration
strategies and architectural solutions can help individuals and organizations in determining how to migrate existing
software applications to the cloud.

Acknowledgements
CNPq grants 311617/2011-5 and 487174/2012-7 and a Microsoft Research SEIF 2013 Award partially fund this work.

References
1. S. Murugesan, “Cloud Computing: The New Normal?,” Computer, Jan. 2013, pp. 77–79.
2. V. Andrikopoulos et   al., “How to Adapt Applications for the Cloud Environment,” Computing, June 2013, pp. 493–535;
http://tinyurl.com/lw7ykwy.
3. P. Jamshidi et al., “Cloud Migration Research: A Systematic Review,” IEEE Trans. Cloud Computing, vol. 1, no. 2, 2013, pp.
142–157.
4. Gartner Newsroom, “Gartner Identifies Five Ways to Migrate Applications to the Cloud,” 16 May 2011;
www.gartner.com/newsroom/id/1684114.

 
 Nabor C. Mendonça   is a titular professor in the Center of Technological Sciences at the University of Fortaleza
(UNIFOR), Brazil. His research interests include software engineering, distributed systems, and cloud computing.
Mendonça has a PhD in computing from Imperial College London. Contact him at nabor@unifor.br.

Editor: San Murugesan, BRITE Professional Services, Sydney, Australia; san@computer.org

Cloud, cloud migration, cloud hosting, cloudification

View publication stats