62 COMPUTER Published by the IEEE Computer Society 0018-9162/14/$31.00 © 2014 IEEE

COLUMN SECTION TITLECLOUD COVER

Identifying and examining potential cloud migration constraints and adopting a suitable architectural solution are important steps to facilitate successful application migration to the cloud.

A s cloud computing rapidly becomes the IT industry’s “new normal,”1 organizations

considering whether to adopt this computing paradigm must evalu-ate several sometimes conflicting factors, both technical (migration effort, environmental constraints, performance impact) and nontech-nical (security risks, operational costs, business gain).

Cloud adoption poses particu-lar challenges for organizations whose businesses depend on legacy applications—some of which may rely on program ming languages, system libraries, and execution envi-ronments that aren’t fully supported by or readily available in the cloud. Developers need to anticipate pos-sible hurdles to cloud migration and come up with architectural solutions that circumvent them.2

CLOUD MIGRATION STRATEGIES A typical software application contains several independently de-ployable components—client front

end, application server, database server, and so on. Each component interacts with its own underlying ex-ecution 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 incompat-ibilities between the components’ original operational environment and the cloud operational environ-ment may make this impossible. Consequently, application develop-ers 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 develop-ers 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 migra-tion strategies—hosting potentially modified application components in the cloud or replacing them with ap-propriate 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 de-velopers could use to implement them. Table 1 summarizes the migration context and usage sce-nario for the two cloud mi gration strategies as well as the specific ar-chitectural solutions discussed here.

CLOUD HOSTING Developers’ decisions regarding ar-chitectural solutions to properly host a given application component in the cloud depend on the con-straints the provider may impose on the cloud’s operational environment,

Architectural Options for Cloud MigrationNabor C. Mendonça, University of Fortaleza

r8clo.indd 62 7/24/14 3:22 PM

AUGUST 2014 63

and on how those constraints affect the target software component’s de-ployment and execution.

Several commonly employed so-lutions stand out.

RebindingThe simplest way to deploy an ap-plication component in the cloud is

by rebinding. Here, the developer’s only concern is making sure the target component can restore its state and prop erly reestablish all its external service dependencies after migration.

This solution is predicated on two main conditions: the target component’s original operational

requirements must be fully com-patible 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 com ponents.

A sample scenario appropriate for this solution is migrating a Java

Cloud hosting Cloudi�cation

Before migration

Local environment

C1 C2T1

Rebinding

Service adaptation

Service conversion

Compensation

C2T1

C1’

Cloud environmentLocal environment

C1T1

C2T1

C1 A1T1

A2 C2T1T2 T2

C1’T2

C2’T2

Interface conversion

Replacement

Interface adaptation

C1 S

Cloud environmentLocal environment

Cloud environmentLocal environment Cloud environmentLocal environment

Cloud environmentLocal environment

C1 A

SC1 AT1 T2T1

SC1’T2 T2

After migration

C A

SC’

T

T

Original component

Modi�ed component

Adapter

Cloud service

Required service type

Provided service type

Remote invocation

Disabled service

Cloud environmentLocal environment Cloud environmentLocal environment

Cloud environmentLocal environment

ST1 T2T2

T1 T1

Figure 1. Two migration strategies, cloud hosting and cloudification. The different possible architectural solutions are illustrated for each case.

r8clo.indd 63 7/24/14 3:22 PM

64 COMPUTER

CLOUD COVER

Enterprise Edition (JEE) applica-tion to a JEE container running in a public infrastructure as a service (IaaS) cloud such as Amazon EC2 (http://aws.amazon.com/ec2).

Service adaptationService 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, devel-opers 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 com ponent with which the target component needs to communicate. These two components act as ser-vice adapters, allowing the target

component and the exter nal com-ponent to communicate indirectly across the cloud boundaries.

A sample scenario implement-ing 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 ser-vice, such as Amazon WorkSpaces (http://aws.amazon.com/work-spaces). Here, the Web browser, at the user side, and the virtual desk-top service, at the cloud side, act as the two adapters.

Service conversionService conversion offers a more flexible, albeit more intrusive, alter-native 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 solu-tion 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 re-motely invoke the new Web service in the cloud.

Compensation If there’s no practical way to allow the target component to communi-cate with other external components outside the cloud, a possi ble

Table 1. Recommended strategies and solutions for cloud migration.

Migration context Strategy Solution Example scenario

The target component is fully com patible with the cloud’s operational environment.

Cloud hosting Rebinding Migrating a JEE ap plication to a JEE container running in a public IaaS cloud

One or more of the target component’s external service dependencies are incom-patible with yet can be adapted to operate in the cloud.

Cloud hosting Service adaptation

Migrating a desktop application to a public IaaS cloud with users remotely accessing the application’s GUI through a Web-based virtual desktop service

One or more of the target component’s external service dependencies are incom-patible with yet can be converted to operate in the cloud.

Cloud hosting Service conversion

Converting a file-based batch application into a fully fledged Web service so as to allow its migration to a public IaaS cloud

One or more of the target component’s external service dependencies are irrecon-cilable with the cloud.

Cloud hosting Compensation Disabling or re-implementing thread creation features in a multithread Java application so as to allow its migra-tion to a public PaaS cloud

The state of the target component is trans-ferrable to the cloud, and there is a candidate cloud service with a fully com-patible interface.

Cloudification Replacement Replacing a local relational database server with a cloud-based relational data service

The state of the target component is trans-ferrable to the cloud, and there is a candidate cloud service with an incompati-ble yet adaptable interface.

Cloudification Interface adaptation

Using a customized file system driver to redirect all local disk access to a cloud-based file storage service

The state of the target component is trans-ferrable to the cloud, and there is a candidate cloud service with an incompati-ble yet convertible interface.

Cloudification Interface conversion

Converting a file-based application so that it can access a cloud-based storage service

r8clo.indd 64 7/24/14 3:22 PM

AUGUST 2014 65

alternative is to alter the target com-ponent 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 com-ponent previously required from the other components, or the de-veloper 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 care fully assessed. For instance, disabling a crucial func-tionality may disrupt or seriously compromise the component’s opera-tion in the cloud; incorporating any nontrivial functionality may impact some of the component’s quality at-tributes, 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 ap-plication 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 ap-plication’s multithread features would have to be properly disabled without compromising operation or reimplemented using the cloud’s own thread API prior to the applica-tion’s migration to the cloud.

CLOUDIFICATION Replacing one or more application components with existing cloud services that offer similar or re-lated functionality has two main requirements: there must be candi-date 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 ser-vices in the cloud.

Cloudification usually involves one of the following architectural solutions.

ReplacementLike rebinding for cloud hosting, re-placement is the simplest form of cloudification. But this solution is only feasible if the target compo-nent 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 solu-tion involves replacing an in-house relational database with a cloud-based relational data service such as Amazon RDS (http://aws.amazon.com/rds).

Interface adaptationIf the target component and the candidate cloud service have func-tionally related but incom patible 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 ser-vice’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 archi-tectural 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 custom-ized 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 conversionLike interface adaption, interface conversion addresses the need to replace the target component with a candidate cloud service that has a related but incompatible inter-face. 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 ap-plication components pertinent to the migration must be individually converted in order to access the can-didate service in the cloud.

OTHER MIGRATION CONSIDERATIONS Identifying the most suitable archi-tectural solution for a given cloud migration scenario must also take into account other potential vari-ables 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 possibil-ity of combining different migration strategies and deployment models should be considered.

Effort and quality impact estimationReusing independently deploy-able service adapters as part of a migration solution avoids the need for modifying existing application components to conform with a par-ticular service type, thus reducing the overall migration effort. Another advantage of using adapters is that

r8clo.indd 65 7/24/14 3:22 PM

66 COMPUTER

CLOUD COVER

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 multi-ple adapters acting as intermediaries between local and cloud-based ap-plication compo nents and services can impose significant performance overhead.

Component selectionChoosing which application compo-nents one should host in the cloud or replace with an appropriate cloud service is crucial, and the decision can affect the entire migration pro-cess. For instance, cloud hosting only a subset of application components requires less effort than migrat-ing 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 exchange rate.

Hybrid strategiesNo single migration strategy is likely to meet all of an organization’s tech-nical and business needs. Therefore, organizations should expect to use a combination of architectural solu-tions and deployment models as part of their cloud migration decisions.

For example, an organization might decide to host all application

components with strong security re-quirements 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 appli-cation components in a private cloud and then start to cloudify one com-ponent at a time as they gain more confidence with the public cloud’s operational model.

C loud migration is a non-trivial process that touches many facets of an organi-

zation, from general business needs to more technical decisions about appropriate software architectures and tools. Understanding common migration strategies and architec-tural solutions can help individuals and organizations in determining how to migrate existing software applications to the cloud.

Acknowledgements CN Pq g r a nt s 311617/2011-5 a nd

487174/2012-7 and a Microsoft Research

SEIF 2013 Award partially fund this work.

References1. 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 pro-fessor in the Center of Technological Sciences at the Univer sity of For-taleza, Brazil (UNIFOR). His research interests include software engineer-ing, distributed systems, and cloud computing. Mendonça has a PhD in computing from Imperial Col-lege London. Contact him at nabor@unifor.br.

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

Subscribe today for the latest in computational science and engineering research, news and analysis, CSE in education, and emerging technologies in the hard sciences.

www.computer.org/cise

Selected CS articles and columns are available for free at http://ComputingNow.computer.org.

r8clo.indd 66 7/24/14 3:22 PM