A Model-Driven Approach to Support Cloud Migration Process

Post on 15-Apr-2017

558 views 1 download

Transcript of A Model-Driven Approach to Support Cloud Migration Process

A Model-Driven Approach to Support Cloud Migration Process

Mahdi Fahmideh Gholami

2/43

Research Background

3/43

Background (Continue) Many IT-based organisations are interested in migrating their legacy applications

to cloud environments.

Moving legacy applications to the cloud environments needs to be organised, anticipated, and viewed from a methodological perspective (Mohagheghi, Berre et al. 2010; Chauhan and Babar 2012; Babar 2013; Jamshidi, Ahmad et al. 2013)

Challenges in development applications for cloud environments:

Resource elasticity

Multi-tenancy

Interoperability

Application licensing

Unpredictable environment

Legal issues

4/43

Background (Continue)

Cloud Migration Moving workable legacy software applications to cloud environments.

Cloud Migration Methodology A cloud migration process is a set of migration activities carried to support an

end-to-end cloud migration. Cloud migration processes define a comprehensive perspective, capturing business and technical concerns. Stakeholders with different backgrounds are involved (Pahl, Xiong et al. 2013).

Software Development Methodology Recommended collection of phases, procedures, rules, techniques, tools,

documentation, management and training used to develop a system (Avison and Fitzgerald 2003).

/43

Research Motivations

6/43

Research Motivations

Cloud migration approaches are grounded on a set of common concepts, though they vary in details and may have not been expressed in exactly the same manner.

When collectively viewed, they address relevant issues. Lack of an integrated view of existing cloud migration processes.

Although variety of approaches is profitable at the beginning of a research filed and learn many valuable lessons, an consensual picture (.i.e. a common methodology) of what this bunch of approaches look like is eventually more efficacious.

Existing approaches narrow in detail and are domain-specific. “there is need to detach the cloud application development process from specific Cloud

platforms” (Hamdaqa 2011). Lack of support for method tailoring. One-size-fits-all assumption is fallacious.

7/43

It would be helpful if common concepts in the existing cloud migration approaches could be factored out into one generic and unified model at a convenient abstraction level.

Adequately crafted, it would facilitate to grasp a complete vision of cloud migration process which was transparent and independent of any cloud-specific platform and technology.

A unified access to various migration approaches.

A common language to describe migration processes.

Research Motivations (Continue)

8/43

Model-driven software engineering (MDSE) views development process as a world of models. Models are primary artefacts of development process which are generated and transformed to running software (Stahl, Voelter et al. 2006).

A major strand in MDSE discussion is to design modelling languages for a particular domain, called domain-specific modelling language (DSML).

A DSML to describe the domain in effective manner along with guidelines to specialize it into a given particular context at hand (Gonzalez-Perez and Henderson-Sellers 2008).

Model-Driven Software Engineering

9/43

Metamodeling is an approach in IS and software engineering to capture all constructs in a particular domain of interest and develop a language infrastructure for better knowledge sharing (Atkinson and Kuhne 2003).

A metamodel for a particular domain is a DSML to describe the domain in effective manner along with guidelines to specialise it into a given particular context at hand (Gonzalez-Perez and Henderson-Sellers 2008).

Existing cloud migration approaches can be viewed as various models that describe transition process to cloud environments.

Suitably crafted, it can provide a language infrastructure to freely model a methodology or indeed a family of related methodologies.

Model-Driven Software Engineering

10/43

Research Objective “via metamodeling approach, develop a generic process model for

legacy application migration to cloud environments”

Research Objective

11/43

Research Methodology

Develop an innovative IT artefact which integrates cloud migration approaches into an abstract, versatile enough, and provides a domain language for cloud migration.

A problem/solving endeavour.

This inquiry can be addressed by design science research (DSR) DSR focuses on the problem solving aspects by designing and

prescribing artificial innovations for the IS development (March and Smith 1995; Hevner, March et al. 2004; Vaishnavi and Kuechler 2004).

DSR methodology process for this research (Peffers, Tuunanen et al. 2007)

Problem Identification

and Motivation

Define problem

Show importance

Define the Objectives

for a Solution

What would a better artefact

accomplish?

Design and Development

Artefact

Demonstration

Find suitable context

Use the artefact to solve problem

Communication

Scholarly publications

Professional publicationsIn

fere

nce

Theo

ry

and

app

roac

h

How

to k

nowl

edge

an

d

Iteration

Disc

iplin

ary

know

ledg

e

Evaluation

Observer how effective & efficient

Iterate back to design

Met

rics,

Anal

ysis

know

ledg

e

12/43

A Development of Metamodel for Cloud

Migration Process

DSR methodology process for this research (Peffers, Tuunanen et al. 2007)

Problem Identification

and Motivation

Define problem

Show importance

Define the Objectives

for a Solution

What would a better artefact

accomplish?

Design and Development

Artefact

Demonstration

Find suitable context

Use the artefact to solve problem

Communication

Scholarly publications

Professional publicationsIn

fere

nce

Theo

ry

and

app

roac

h

How

to k

nowl

edge

an

d

Iteration

Disc

iplin

ary

know

ledg

e

Evaluation

Observer how effective & efficient

Iterate back to design

Met

rics,

Anal

ysis

know

ledg

e

13/43

Research Methodology

14/43

Step 1— Preparing Knowledge Sources for Metamodel Creation

15/43

Systematic literature review (Kitchenham, Pearl Brereton et al. 2009) A well-recognized procedure to identify, analyse, and interpret all relevant studies

regarding a particular topic of interest. Search Strings

The main terms “Cloud”, “Cloud Computing”, “Service Computing”, “Legacy”, “Methodology”, “Process Model”, “Reference Model”, and “Migration”

Selected Study Sources IEEE Explore, ACM Digital Library, SpringerLink, ScienceDirect, Wiley InterScience, ISI Web of Knowledge,

Google scholar. Inclusion criteria: validated using example application, simulation, empirical study (case study,

controlled experiment), or experience from real examples.

Step 1— Preparing Knowledge Sources for Metamodel Creation (Continue)

16/43

78 Studies Identified existing methodologies, general approaches/frameworks, industrial experiences, patterns, decision

making framework .

Step 1— Preparing Knowledge Sources for Metamodel Creation (Continue)

17/43

Demographic Data

Step 1— Preparing Knowledge Sources for Metamodel Creation (Continue)

18/43

Extracting Constructs (e.g. tasks, work-products)— An example

The extraction of constructs from Chauhan and Babar’s Methodology

Construct selection criteria: Relevant to challenges in cloud

application developmentSufficiently generic (very

technical constructs excluded)

Step 1— Preparing Knowledge Sources for Metamodel Creation (Continue)

19/43

Extracting Constructs- An example

In total 511 constructs were identified.

Step 1— Preparing Knowledge Sources for Metamodel Creation (Continue)

20/43

An excerpt of extracted construct definitions

Step 1— Preparing Knowledge Sources for Metamodel Creation (Continue)

21/43

Step 2— Creating the Target Metamodel

22/43

Step 2— Creating the Metamodel

The gradual formation of metamodel

23/43

Step 2— Creating the Metamodel

Choose Cloud Provider

Step 2.1 Grouping Similar Constructs— an iterative approach An example: 35 studies refers to the notion of cloud provider selection

24/43

Step 2— Creating the Metamodel (Continue)

Step 2.1 Grouping Similar Constructs— an iterative approachIteration 1:

Generic software development lifecycles (Pressman 1992; Sommerville 2004)Generic reengineering lifecycles including Butterfly (Wu, Lawless et al. 1997),

Renaissance (Warren and Avallone 1999), Sneed’s approach (Sneed 1995), and Architecture-Driven Modernization horseshoe (Khusidman and Ulrich 2007)

Challenges in cloud application development, [S10], and [S68]Iteration 2:

Work-productsGeneric software development introduced, generic reengineering lifecycles

Iteration 3:Restructuring and perfecting

Tuning granularity of constructs (Henderson-Sellers and Gonzalez-Perez 2010)An example of decomposition: Enable Multi-Tenancy - > Isolate Tenant Data,

Isolate Tenant Performance, Isolate Tenants Availability, Enable Application Customisation [S35], [S65] and (Bezemer and Zaidman 2010)

Output: 72 common constructs, i.e. 65 tasks and 7 work-products.

25/43

Step 2— Creating the Metamodel (Continue)

Step 2.2 Harmonising the Constructs’ DefinitionsThere is a link between different definitions Reconciliation of the various definitions

An Example: Choose Cloud Provider

26/43

Step 2— Creating the Metamodel (Continue)

An Example: Choose Cloud Provider

27/43

Step 2— Creating the Metamodel (Continue)

Step 2.3 Organising the 72 Constructs Three hierarchical levels (based on SPEM OMG 2002)

PhaseBased on [S4], [S10], [S68]: Four phases Plan, Design, Enable, and Maintain

ActivityTask and Work-product

28/43

Step 2— Creating the Metamodel (Continue)

Step 2.4 Defining the Relationships Between the Constructs

Association, Specialisation and Aggregation Uses Association

Follows Association the sequence of the execution of the migration

process Aggregation

The constructs with a common theme were grouped into a coarse grain activity

Specialisation A construct is a specific kind of another construct

29/43

Step 2— Creating the Metamodel (Continue)

30/43

Step 2— Creating the Metamodel (Continue)

An ExampleAn application is analysed to assess its compatibility with the potential cloud

computing environments. For example, it may be the case that a target PaaS

cloud does not support frameworks or specific technologies being used by an

application. If such issues are identified, then these need to be resolved first”

Chauhan’s methodology (denoted by [S9])

31/43

Resultant Metamodel (the initial version)

32/43

Resultant MetamodelPlan Phase class of constructs

33/43

Resultant MetamodelPlan Phase tasks and their definitions

34/43

Resultant MetamodelDesign Phase class of constructs

35/43

Resultant MetamodelDesign Phase tasks and their definitions

36/43

Resultant MetamodelEnable Phase class of constructs

37/43

Resultant MetamodelEnable Phase tasks and their definitions

38/43

Resultant MetamodelMaintain Phase classes of constructs

39/43

Resultant MetamodelMaintain Phase tasks and their definitions

40/43

Resultant MetamodelWork-Products

41/43

Contributions and Future Work

42/43

Research Contributions

The proposed metamodel Facilitates understanding of cloud migration process Addresses the need for future cloud standardisation Gives insight to practitioners about what cloud migration process entails Provides an extension support for existing methodologies that do not support

cloud computing Acts an evaluation framework to assess existing methodologies for their support

of cloud migration Future Work

Experts’ feedback Applying the metamodel in real-world cloud migration scenarios

DSR methodology process for this research (Peffers, Tuunanen et al. 2007)

Problem Identification

and Motivation

Define problem

Show importance

Define the Objectives

for a Solution

What would a better artefact

accomplish?

Design and Development

Artefact

Demonstration

Find suitable context

Use the artefact to solve problem

Communication

Scholarly publications

Professional publicationsIn

fere

nce

Theo

ry

and

app

roac

h

How

to k

nowl

edge

an

d

Iteration

Disc

iplin

ary

know

ledg

e

Evaluation

Observer how effective & efficient

Iterate back to design

Met

rics,

Anal

ysis

know

ledg

e

43/43

Thank You