Migrating e-Science Applications to the Cloud: Methodology and Evaluation - Cloud Computing with e-Science Applications - page 98

FR 5 Support for Incompatibility Identification and Resolution : Any potential incompatibilities

(e.g., between SQL versions supported by different data services) must be identified,
and guidance must be provided on how to overcome them. For this purpose, the
methodology has to incorporate the specification of functional and nonfunctional
requirements for both the (source) database layer used before the migration and the
target data store or data service.

FR 6 Support for Various Migration Scenarios : As the data migration depends on the context

and the concrete use case (e.g., backup, archiving, or cloud bursting), the methodology
has to support various migration scenarios.

FR 7 Support for Refactoring of the Application Architecture : The amount of refactoring of the

application architecture during the migration of the database layer to the cloud depends
on many aspects, such as the supported functionalities of the target data store or data
service, use case, and so on. It is therefore required that the methodology provides
guidance and recommendations on how to refactor the application architecture.

5.4.1.2 Nonfunctional Requirements

In addition to the required functionalities, a methodology for migra-
tion of the database layer to the cloud and refactoring of the application
architecture should also respect the following properties of nonfunctional
requirements (NFRs):

NFR 1 Security : Both data export from a source data store and data import to a target data

store require confidential information such as data store location and access
credentials. Any tool supporting the methodology should therefore consider
necessary authorization, authentication, integrity, and confidentiality mechanisms
and enforce user-wide security policies when required.

NFR 2 Reusability : As the migration of data can be seen as either the migration of only the

database layer or as part of the migration of the whole application, the methodology
has to be reusable with respect to the integration into a methodology for migration
of the whole application to the cloud, such as the one proposed by Varia for Amazon
(Varia, 2010).

NFR 3 Extensibility : The methodology should be extensible to incorporate further aspects that

have an impact on the data migration to the cloud, such as regulatory compliance.
For example, in the United States, the cloud service provider is responsible for
ensuring compliance to regulations (Louridas, 2010), but in the European Union, it is
the cloud customer that is ultimately responsible for investigating whether the
provider realizes the Data Protection Directive (Cate, 1994).

5.4.2 Migration Methodology

The step-by-step methodology we introduce in this section refines and
adapts the migration methodology proposed by Laszewski and Nauduri
(2011) to address the identified requirements. The methodology (Laszewski
and Nauduri, 2011) consists of seven distinct phases (Figure 5.2). During
the Assessment phase, information relevant for project management, such as
drivers for migration, migration tools, and migration options, is collected