Cloud Readiness Assessment of Legacy Application

Flavio Corradini, Francesco De Angelis, Andrea Polini and Samuele Sabbatini

School of Computer Science, University of Camerino, Via del Bastione 1, Camerino, Italy

Keywords:

Cloud Assessment, Cloud Migration, Software Evaluation, Reengineering, Cloud Application Portability,

Cloud Governance.

Abstract:

Applications and services hosted in the cloud are increasing continuously. Cloud technology offers important

perspectives (performance, high availability, elasticity) and it enables new business models. Unfortunately,

this new paradigm faces unprecedent requirements not addressed in legacy application (multi-tenancy, scala-

bility, etc.). This leads to complex re-engineering phases in order to to migrate existing software into a cloud

environment. Before starting a migration, it is important to analyze the cloud compliance of the application,

what to expect after the migration and the effort required to fulﬁll these expectations. This paper assesses

a way to extract an index that describes the feasibility of the re-engineering. We test the metric with a real

application that needs to be migrated to a private cloud.

1 INTRODUCTION

Migrate legacy application to the cloud is one of the

biggest challenges that cloud paradigm has brought

(Buyya et al., 2010). Although the concept of util-

ity computing was introduced about ﬁfty years ago

(Parkhill, 1966) , it began to be a commercial need

only in the early 2000s. The fact that this new

paradigm is driven by commercial aspects and not

from a real scientiﬁc study has led to the creation of

different deﬁnitions (Vaquero et al., 2008) depending

on the commercial context. NIST (Mell and Grance,

2011) provides the most used deﬁnition of cloud. The

cloud is totally revolutionary in software develop-

ment as foundries have been in the hardware industry

(Armbrust et al., 2009). This model is completely de-

tached from the past, but it results in some problems.

One of the main being the ability to migrate legacyap-

plication developed with previous methodologies into

a new environment and making them cloud compli-

ant. This challenge is due to the fact that legacy appli-

cation have been implemented with previous methods

without taking into considerations concepts unknown

until the advent of cloud (i.e. elasticity and scalabil-

ity) (Menychtas et al., 2013). To migrate a legacy

application in a cloud environment, it is necessary to

update the application to exploit these new capabil-

ities. To do this, it is necessary to evaluate the ap-

plication to migrate how and where the application is

to be evolved. On the other hand, as mentioned previ-

ously, the cloud is not a unique concept, and so this as-

sessment should also take into account the technology

used in the cloud infrastructure. This article presents

the deﬁnition of a metric to evaluate the compliance

of an application respect to a cloud environment. This

proposed research is related to the Open City Platform

project (OCP project) founded by the Italian Min-

istry (Ministero dellIstruzione, dellUniversita e della

Ricerca) in the Smart Cities and Communities and

Social Innovation initiative(OCP, 2014). This project

aims to migrate the applications used by some Public

Administration in an private cloud infrastructure. In

this context, the metric will be based mainly on tech-

nological concepts, ignoring the change in business

models nedeed in a migration to a public cloud. The

presented metric will be based on the speciﬁc request

of this environment, and it will also be portable in or-

der to be applied in other contexts. In Section II, the

state of the art is analyzed. In Section III, the met-

ric is proposed. Section IV will focus on the results

provided by the metric. In Section V the application

context is presented. The paper ﬁnishes with a section

of Conclusions.

2 RELATED WORK

These last years, the issue of cloud migration was

faced by researchers and industrials and a quite va-

riety of solutions were presented.

Di Biase (Biase, 2013) proposes a questionnaire

119

Corradini F., De Angelis F., Polini A. and Sabbatini S..

Cloud Readiness Assessment of Legacy Application.

DOI: 10.5220/0005443301190126

In Proceedings of the 5th International Conference on Cloud Computing and Services Science (CLOSER-2015), pages 119-126

ISBN: 978-989-758-104-5

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

to evaluate both organizational and application migra-

tion in order to identify which migration type can be

applied. Hosseini et al. (Khajeh-Hosseini et al., 2012)

propose a migration tool-kit that involves all decision

making in order to evaluate the feasibility of the ap-

plication. Related to our work the application assess-

ment is a list of question divided in different areas. Vu

et al. (Vu and Asal, 2012) proposes a methodology

approach is presented in order to establish which step

are needed in legacy application evaluation process.

ARTIST (Artist, 2014) and REMICS (Remics,

2014) are two projects very closed to the aim of the

research herein. These projects are funded by the

European Community, and they focus their aim on

migration using Model Driven Engineering (OMG,

2014). Both projects aim to develop different tools

of different part of the migration. REMICS ended in

the 2013 and it focused the attention on the recov-

ery, migration, validation and supervising processes

of the migration itself. However this project did not

cover challenges such as elasticity, multi-tenancy and

other non-functional properties. ARTIST focuses on

migrating legacy software written in Java and C. The

project is still open and it tries to support the migra-

tion in every aspect. Strictly related to the purpose of

this article, ARTIST presents a work (Alonso et al.,

2013) strictly related to the purpose of this article,

where the pre-migration phase of the project is pro-

posed. The method used to elaborate the maturity of

the software is a questionnaire that has to be answered

by a person with a good knowledge of technical and

businesses aspects.

The evaluation of legacy application is a busi-

ness used also by big cloud infrastructure player.

Company such as Ibm (IBM, 2014), Cisco (CISCO,

2014), VmWare (VmWare, 2014) and other (RedHat,

2014) (Rackspace, 2014) (Amazon, 2014) offer a self-

assessment tool or whitepaper to evaluate the advan-

tages to migrate the application in their cloud. How-

ever, the problem of these approaches is that they are

based on closed proprietary tools that are not widely

available; and they are often accompanied by expen-

sive consultancy periods. The advantage of our pro-

posed metric is to create an agile process in order to

ﬁll out complex questionnaires readily.

3 EVALUATION CRITERIA

This section will presents the metric to assess if a

legacy application is cloud compliant. This metric an-

alyzes a series of questions that are asked to the soft-

ware engineer. These questions are used to analyze

the current state of the application and the status that

should be achieved by migrating to the cloud. For

the realization, the following categories were taken

into account: (a) Workload, (b) Application Type,

(b) Component, (c) Loose Coupling, (d) Distributed

application, (e) Security, (f) Multi-Tenancy and (g)

Database. Each category was then divided into sev-

eral sub-categories in order to be able to identify the

level of applications cloud compliant relating to spe-

ciﬁc category.

3.1 Workload

To migrate an application from in-house environment

to cloud, it is necessary to take into account the work-

load. In Cloud computing patterns (Leymann et al.,

2013) presents 5 different workloads: (a) Static, (b)

Periodic, (c) Once a life, (d) Continuously grow and

(e) Elastic. This paragraph goes in details of each type

of load will be presented.

An application with static workload does not take

any advantage to be migrated into cloud. This is due

to the elasticity concept. Indeed, a static workload

needs the same resources over the time, this means

that having the automation in the allocation and deal-

location of resources is almost useless. The migra-

tion of application with periodic workload into cloud

will exploit the concept of resources elasticity. On the

other hand, this workload is often too easy to be pre-

dicted, so it is possible to avoid the cloud by providing

the necessary resources to meet the peak load and this

would lead to a waste of resources during other pe-

riods. Once a life workload consists in a static load

with rare peak of resources utilizations. This It re-

sults to be more advantageous than periodic load due

to the fact that the single peak cannot be predicted so

if in-house solution is used it would be probable to re-

main without sufﬁcient resources. Continuously grow

workload nearly represents the optimal case in which

cloud migration will adds many advantages. In this

type of load, the necessary resources grow with time

and an automation of resource allocation would bring

many beneﬁts. In a static environment (in-house), this

type of load would result in many problems as there

would be either a state of over-sizing of the allocated

resources or a lack of resources when the load has

exceeded its capacity. This then leads to a waste of

money when the available resources are greater than

the actual demand, and it lacks of reliability and per-

formancewhen the required resources are greater than

those actually available. The cloud instead, thanks

to its elasticity, allows the resources provided to be

exactly those needed. For that reason Elastic work-

load is the optimal load for which the migration to

the cloud is essentially required.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

120

3.2 Architecture Type

The number of layer by which is divided the appli-

cation is very important. The layers are a logical di-

vision that separate the various application processes

and make them independent. Obviously, this type of

classiﬁcation is related to the server part. The ap-

plications that are taken into account are the classic:

(a) 1-Layer: Monolithic, (b) 2-Layer, (c) 3-Layer (or

more), (d) client-server.

1-Layer application has no subdivision, stateless

and stateful components are related to each other and

then it becomes difﬁcult to carry out policies of scala-

bility. In 2-Layer application, it is possible to iden-

tify a data layer and a Presentation & Logic layer.

This division helps the migration phase due to the fact

that a division between stateful and stateless compo-

nents has already been executed. Thus, the top layer

can scale without any problem and not having to deal

with the data redundancy. Applications with 3 or

more layer have a physical and logical subdivision

already well deﬁned. Each layer is able to be inde-

pendent and satisfy a given operation. In a cloud en-

vironment, this subdivision allows a migration faster

than the other cases giving the chance to each layer

to scale. Client-Server application is another com-

mon architecture used in legacyapplication. This type

of architecture has different problems when it is mi-

grated into the cloud. In the cloud model the client

part of the application has to be converted to work in

a cloud infrastructure. However, if the migration af-

fects only the server, this type of application could be

seen as one of the previous speciﬁcation.

3.3 Component

The analyses of components that would be migrated

is an important aspect to be considered when a mi-

gration in cloud is performed. With the term compo-

ment we consider a software element that conforms

to a component model and can be independently de-

ployed and composed without modiﬁcation accord-

ing to a composition standard. Regards this cate-

gory three different components are take into account

herein: (a) Stateful with Strict Consistency, (b) State-

ful with Evenutal Consistency, (c) Stateless.

Stateful with Strict Consistency components being

the most difﬁcult to migrate to cloud. The consistency

must be guaranteed in all its replicas, thus the system

must be able to keep synchronized all copies. The

system needs a lot of work to fulﬁl this problem and

when the number of replicas grows exponentially the

performance of the system highly decreases.Stateful

components can be accessed without having read the

most updated data. It is not possible to use this model

on critical components, which are the ones where in-

formation must be precise. That is why it is impor-

tant to make sure data are as up-to-date as possible

when read. In case of several instances, the updates

are not executed synchronously but asynchronously,

thus allows a better response. In a cloud view, this

kind of component is able to scale much more easily

than the previous one. Stateless components have no

information that needs to be duplicated or updated in

the other instances. This means it does not undergo

efﬁciency loss as the number of replicas increases.n

a cloud environment, the resources for components

would be 100% exploitable, as they do not need any

policy to be implemented and the updating of the data

could be both asynchronous and synchronous.

3.4 Database

The database level is probably the most delicate to

migrate. In order to achieve a good level of scal-

ability the usage of NoSQL databases is recom-

mended. However most legacy application uses Re-

lational DataBase (RDB). Great might be the effort

to migrate data from this databases to NoSQL, both

in terms of to reengineering the database and migrate

the data. This might result in discouraging this migra-

tion. Therefore, it is important to consider that com-

ponents are only stateful at this level and data must

remain intact. So, the issues to be considered are re-

markable. The following list shows different database

types: (a) relational database with stored procedure

(SP), (b) RDB without SP, (c) RDB divided by area

and (d) NoSQL.

Relational databases with Stored Procedures are

the worst cases of migration to cloud. Until the ad-

vent of the cloud, using stored procedures was rec-

ommended as they were able to speed up and op-

timize the process. This also allowed to not have

large deployment of resources for components that

were not DB. With cloud and the theoretical avail-

ability of inﬁnite and elastic resources, it is better

to demand processing and workload to components

able to scale without problems. Consequently, the

part of the application more difﬁcult to scale will be

weighed down by stored procedures that load static

components. As mentioned before, stored procedures

are not recommended in cloud environment, due to

the fact that they load components difﬁcult to scale.

Without stored procedures, the database must perform

only the necessary operations on the data, without ex-

cessively overloading the database. All applications

that use multiple relational databases without stored

procedure apply to another sub-category of Database

CloudReadinessAssessmentofLegacyApplication

121

classiﬁcation. The data layer of the application con-

sists of multiple databases where each database has

speciﬁc competences. In this case, the migration to

cloud is better than in the previous cases since the

size of the components different types of access are

created, and the overhead of an area does not affect

the performance of the other. NoSQL databases are

the best for the migration to cloud. All non-relational

database are included in this category. They are very

useful because they can scale very easily and there-

fore the bottleneck that relational databases have is

no longer present.

3.5 Loose Coupling

Loose coupling is another feature to be considered

when an application is migrated to cloud environment

is the component autonomy. A component is consid-

ered autonomous when its changes do not affect the

other ones or vice-versa. With reference to the appli-

cation elasticity in the cloud, components with a low

level of autonomy make them difﬁcult to divide, and

then it becomes difﬁcult to manage the scalability of

a single component. Components with high auton-

omy can be scaled without affecting the other com-

ponents with which it interacts. Starting from the 7

levels presented in (Krafzig et al., 2005), 5 levels of

components autonomy were considered relevant dur-

ing the migration: (a) Physical, (b) Format, (c) Time,

(d) Reference, (e) Platform.

The highest level of coupling is the Physical one,

in this conﬁguration the migration in the cloud is very

difﬁcult to accomplish unless a review of the applica-

tion is performed. A direct physical connection has a

number of limitations. In this context, it is very com-

plicated to undertake policies of scalability is since

the increase of instances of a component implies ma-

jor changes on how it interacts with the other com-

ponents. Format coupling is intended for the com-

ponents that are interfaced through a common for-

mat. The limitations are minor compared to a phys-

ical coupling carrying this speciﬁc type of applica-

tions on cloud has relevant advantages. However, this

dependency leads to great limitations to the compo-

nent.A component that does not have to be synchro-

nized with other components falls into Time clou-

pling. The level of autonomy in this case starts to

become signiﬁcant, and the advantages resulting from

the migration to cloud become clear. At this level, a

component can exchange data with another one even

if it is not available or it works at different speeds.

In a cloud environment the component is easily scal-

able, thus achieving the beneﬁts of scalability with

little difﬁculty.A component is autonomous at a refer-

ence level when it does not need to know the address

of other components to interact with them. In this

case, the autonomy of the component is very high so

moving component in a cloud environment does not

create problems. With a platform autonomy, the com-

ponent does not have any binding to the others, it can

be implemented in any technology, and this would not

affect the behavior of components around him. It is

the best solution for a migration to cloud, each com-

ponent is in fact completely independent on the other

and it can perform all the operations without interfere

with the other components.

3.6 Distributed Application

The migration on cloud of a distributed application

can be easier that migrating other applications. In-

deed, this means that Loose Coupling and Compo-

nents concepts have already been taken into account.

There are 3 different classiﬁcation in distributed ap-

plication: (a) pipe based through message, (b) process

based, (c) layer based.

In pipe based through message distributed appli-

cation, the division is made through the data. The

components expect a certain input and provide cer-

tain output. Often, pipes and ﬁlters are used check

the data format to ensure that the ”chain” between all

components works. A process based distributed ap-

plication is an application that focuses on decomposi-

tion based on business models. In this kind of appli-

cations, it is necessary to have an engine for the man-

agement of the processes, which manages each step

of the application and ensures a proper work and the

order of the components. A layer based distributed

application decomposes the application into separate

logical layers. Each layer is made of application com-

ponents providing a certain function. Components are

restricted to access components of the same layer or

one layer below.

3.7 Multi-tenancy

Multi-tenancy is basis concept of cloud environment,

that terms indicate the use of a single instance of the

software by multiple tenants. The value deﬁned to this

category are: (a) multiple instance in separate hard-

ware, (b) hardware in common with dedicated virtual

machine for each tenant, (c) shared middle-ware with

separated address space and multiple application in-

stances and different db, (d) shared middle-ware with

separated address space and multiple application in-

stances and (e) shared middle-ware and one applica-

tion instance.

In multiple instance in separate hardware, the

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

122

multi-tenancy is not yet implemented. Each client

organization has a dedicated stack from hardware to

application level. In hardware in common with ded-

icated virtual machine for each tenant, the various

tenants are located in the same physical machine in

which VM were created speciﬁcally for each tenant.

This conﬁguration is not yet possible to be considered

as multi-tenancy due to the fact that a large part of the

stack is completely dedicated. Shared middle-ware

with separated address space and multiple applica-

tion instances and different db manages the multi-

tenancy for a large part of the stack. Middle-ware in

this case is in common, and only the application part

is still runing at one instance per tenant. Although

middle-ware is shared in this conﬁguration, it is pos-

sible to see that the database uses different structures

and tables depending on the tenant reference. Shared

middle-ware with separated address space and mul-

tiple application instances is similar to the previous

one, the only noticeable difference is in the manage-

ment of data. In this case, the data of the various ten-

ant reside on the same tables and there are no ded-

icated tables for each tenant. The rest remains un-

changed, with middle-ware shared among multiple

tenants and an application instance for each tenant.

In shared middle-ware and one application instance

the entire stack is managed through the multi-tenancy

model. The tenant access to the same application in-

stance and so the entire stack is shared. This is the

best case for a migration to cloud because it makes

the most out of this paradigm.

3.8 Security

Security is another key issue for cloud environment,

even if in our context this problem is very mitigated.

In our case, we are talking about private cloud where

will run own applications. This differentiates our

model from the classic scene where public cloud is

taken into account. Despite the context fades this is-

sue, it is always important to take security into con-

sideration. In our case the security concerns basically

two aspects: permissions and data protection. This is

the only category that is divided in other categories

due to the different meaning of security. The result of

this category is the sum of the value of Authorization

and Data Protection.

3.8.1 Authorization

The ﬁrst aspect of security taken into account con-

cerns the Permissions. Access management is very

important in cloud because of the multi-tenancy, that,

as explained above, must manage multiple tenants on

the same instance. For this reason, the applications

were classiﬁed as: (a) application without login, (b)

application with simple login, (c) application with lo-

gin managed by roles

3.8.2 Data Protection

The data protection is the second aspect to be consid-

ered in security. The classiﬁcation in this case con-

cerns the type of data, considering whether they are

sensitive or not, and whether they are encrypted or

not. This classiﬁcation is due to the fact that having a

shared environment requires special attention to data

protection and it is extremely important for the data

not to be violated by unauthorized users.

4 MIGRATION ASSESMENT

The objectiveof the metric is to provide to the user the

cloud compliance of an application. To deﬁne a clear

output, two modes were deﬁned: a numeric output

represented by three values, and a graphical output.

To perform the assessment, for each category and sub-

category we assigned a speciﬁc value (Table 1). The

values assigned in this article have been set accord-

ing to our infrastructure. However it can be changed

depending on the needs of the cloud service provider

that delivers the platform and the questionnaire of the

assessment.

In order to calculate the metric, the users ﬁlls out

a questionnaire of technical questions in order to de-

ﬁne the positioning of the application in the various

criteria. In addition, the questionnaire presents some

questions to determine which would be the goal of

the migration. Indeed, to exploit the potential of the

cloud, it is not necessary that the application reaches

the maximum value in each category to exploit the

potential of the cloud. The metric provides values

for the current state (equation 3) and the ﬁnal one

(equation 4) for each category. These extracted val-

ues are then processed according to the equations 5

and 6. These values represent the percentage of ac-

tual (equation 5) and future (equation 6) application

compliance respect to the cloud provider (equation

5). These two values are used to extract the percent-

age of fulﬁlment of the desired objective (equation 7).

This is the most important value of the metric. This

value can be used to estimate the effort of the migra-

tion in terms of time. This calculation can be made

taking into account the costs of the implementation

of the software until now, and relate them to the in-

dex presented in equation 7. Although this effort is

not predictable in a precise way, the index can help in

the estimation when it is calculated for more that one

CloudReadinessAssessmentofLegacyApplication

123

Table 1: Weight of Categories and Sub-Categories.

WORKLOAD 10

- Unknown 0

- Static 2

- Periodic 6

- Once a life 7

- Continuously grow 9

- Elastic 10

LOOSE COUPLING 8

- Physical 0

- Format 2

- Time 4

- Reference 7

- Platform 10

NUMBER OF LAYER 7

- No (1-Layer) 0

- client-server 2

- 2-Layer 5

- 3+-Layer 10

DISTRIBUTED APPLICATION 5

- No 0

- Pipe Based through message 7

- Process Based 9

- Layer Based 10

DATABASE 9

- RDB with SP 0

- RDB without SP 4

- RDB divided by area 7

- NoSQL 10

COMPONENT 8

- Stateful with Strict Consistency 2

- Stateful with Evenutal Consistency 6

- Stateless 10

MULTI-TENANCY 9

- Multiple instances in different separate

hardware

- Hardware in common with VM for each

tenant

- Shared middelware, separated address

space, multiple application instances,

different DB

- Shared middelware, separated address

space, multiple application instances

- Shared middelware and one application

instance

SECURITY 8

- AUTHORIZATION 5

No Login 0

Simple Login 2

- DATA PROTECTION 5

Non encypted sensitive data 0

Non encrypted non sensitive data 2

Encrypted sensitive data 4

Encrypted non sensitive data 5

application, the underline implementation technology

is comparable, and we know the effort made in other

migrations.

n = Number of Categories (1)

= Weight of the Category i (2)

i,x

= Current value of the Category i (3)

i,y

= Desidered value of the Category i (4)

∑

i=1

·V

i,x

)

∑

i=1

·V

i,max

)

· 100 (5)

∑

i=1

·V

i,y

)

∑

i=1

·V

i,y

)

· 100 (6)

= V

· 100 (7)

A radar chart was chosen to represent graphically

the results. The choice fell on this type of chart be-

cause it gives the possibility to have a rough assess-

ment of the status of the application and to understand

what are the gaps to be faced. The various categories

are represented in each edge of the chart. By means of

the questionnaire previously issued, each edge shows

two values representing the score obtained by the ap-

plication in a category. The ﬁrst value is related to

the current state of the application, while the second

one refers to the value that should be achieved when

migrating to the cloud. As mentioned above, each

category has a different score, so before the chart is

drawn, all the values are normalized according to the

weight of the category. The difference lies in the ef-

fort that must be put in before the migration. More-

over, radar chart allows the increasing or decreasing

of various edges without changing the meaning of

it, that advantage permit to export the assessment in

other environments only conﬁguring the metric.

Figure 1: Example of radar results after the evaluation.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

124

4.1 Metric Utilization Example

In this section we introduce an example of the metrics

presented above using an application that handles the

calculation of vehicle taxes.

4.1.1 Questionnaire

The questionnaire is composed of a set of questions

with multiple answers, each answer is needed to ex-

trapolate one of the value presented in the Table 1.The

set of questions regarding ”database” criteria is pre-

sented in Fig. 2 as example. The question regards

both current status of the application ( i.e. Q1-Q2-

Q3) and future status (i.e. Q4). When the question-

naire is completed the system elaborates the answer to

select proper value. In example, Fig. 2 shows how the

ﬁrst three questions allow us to extrapolate the current

value of the application (i.e. RDB with SP”, value =0)

whereas the fourth one refers to the value the applica-

tion would have after the migration (i.e. RDB divided

by area, value=7).

Figure 2: Database’s questionnaire section.

4.1.2 Results

In this section we present the results of the application

tested. The results of the questionnaire are presented

in Table 2( the database values are already explained

in the previous section). These values are then used

to calculate the indexes presented earlier. The results

of the elaboration are: V

= 32.25 %, V

= 56.125

%, V

= 57,461 %. As said in the previous para-

graph, V

is the important value. Indeed, this value

can be used in particular application ( such as homo-

geneous applications) to estimate the effort needed for

the migration. Considering the effort used until now

to achieve V

, it is possible to estimate the effort nec-

essary to complete the migration. The ﬁgure shown

previously (Fig.1) represents the results of this elabo-

ration in a graphical manner. Every edge has a max-

imum value ﬁxed to 100 ( W

max

·V

max

), the value of

the current application (dark grey) is (W

·V

i,x

) (in the

Table 2: Questionnaire’s results of example application.

CATEGORY CURRENT

VALUE

FUTURE

VALUE

Workload(10) Periodic (6) Periodic (6)

Loose Cou-

pling(8)

Time (4) Reference (7)

N Layer(7) 3+ -Layer (10) 3+ -Layer (10)

Distributed

App.(5)

No (0) Layer Based

(10)

Database(9) RDB with SP

(0)

RDB divided

by area (7)

Component(8) Stateful with

eventual con-

sistency (6)

Stateful with

eventual con-

sistency (6)

Multi-

Tenancy(9)

Multiple in-

stances in

different sepa-

rate hardware

(0)

Shared middel-

ware, separated

address space,

multiple app.

instances, diff.

DB (6)

Security(8) Simple Login +

Encrypted sen-

sitive data (7)

Simple Login +

Encrypted sen-

sitive data (7)

example 9· 0 = 0) and the desired value (light grey) is

·V

i,y

) (in the example 9· 7 = 63).

5 FUTURE WORK AND

CONCLUSIONS

The next step will test the assessment other applica-

tion involved in OCP project in order to better validate

the index. Moreover, the presented metric is used to

evaluate software engineering aspects. However, the

adoption of cloud computing involves all the aspects

of the enterprise. The aim is to integrate this evalu-

ation metric with other metrics that evaluate business

and organizational aspects. The integration with other

metrics imply the automation of the metric in order to

have a migration methodology to automate the entire

process ( Fig. 3). The idea is to use Model Driven En-

gineering to extract information directly from the arti-

facts in order to have as accurate information. In this

way the questionnaire to submit will undergo to some

changes. The deﬁned weights will also be automated

in order to have the assessment made automatically

from a data storage in which patterns and services

of the cloud infrastructure are described. The cru-

cial aspect of this assessment is the value presented in

equation 7 that is used to estimate the effort needed to

the migration. The proposed estimation of effort uses

generic assumption. The idea is to study in depth how

CloudReadinessAssessmentofLegacyApplication

125

it would be possible to improve the accuracy of the

estimation effort by transforming it to person/month

or other valuable metrics. Another output will gener-

ate documents describing the weakness of this evalu-

ation. These documents will be used as an input by

the modernization process of the application that will

perform an evolution of the application even going

to insert, where possible, speciﬁc patterns of the in-

frastructure to create optimal Platform Speciﬁc Model

(PSM). The objective of these implementations is: (a)

to have a precise and clear situation through auto-

mated processes, (b) to make the metric portable in

other contextes.

Figure 3: High level architecture diagram of a migration

phase related with the metric.

Public institutions suffer the issue of legacy ap-

plication migration to the cloud. They offers a wide

range of heterogeneous services to citizen, company

and other institution and they could take advantage

from cloud computing handling automatically and dy-

namically resources. The metric proposed in this pa-

per is intended to helps public institution that wants

to create private cloud infrastructure with services in-

stalled in it. Considering the context of the OCP

project, in which this research is performed, it was

decided to consider only the technological part of the

migration ignoring aspects of business. At the same

time, a platform independent setting was given not to

limit the metric only to this case but to apply it in other

areas.

ACKNOWLEDGEMENTS

This work has been supported by the Open City Plat-

form project and EUREKA project funded by Re-

gione Marche, UNICAM and APRA SpA.

REFERENCES

Alonso, J. et al. (2013). Cloud modernization assess-

ment framework: Analyzing the impact of a poten-

tial migration to cloud. In Maintenance and Evo-

lution of Service-Oriented and Cloud-Based Systems

(MESOCA), pages 64–73. IEEE.

Amazon (2014). http://media.amazonwebservices.com/-

cloudmigration-main.pdf.

Armbrust, M. et al. (2009). M.: Above the clouds: A berke-

ley view of cloud computing.

Artist (2014). Artist project. http://www.artist-project.eu/.

Biase, F. D. (2013). Legacy to cloud migration: Assessing

the cloud readiness of legacy software systems. Mas-

ter’s thesis, University of Applied Sciences Western

Switzerland.

Buyya, R., Ranjan, R., and Calheiros, R. N. (2010). Inter-

cloud: Utility-oriented federation of cloud computing

environments for scaling of application services. In

Algorithms and architectures for parallel processing,

pages 13–31. Springer.

CISCO (2014). . http://www.ciscowebtools.com/cloud.

IBM (2014). http://www-01.ibm.com/software/rational/

info/cloud-services/self-assessment.htmls.

Khajeh-Hosseini, A., Greenwood, D., Smith, J. W., and

Sommerville, I. (2012). The cloud adoption toolkit:

supporting cloud adoption decisions in the enterprise.

Software: Practice and Experience, 42(4):447–465.

Krafzig, D., Banke, K., and Slama, D. (2005). Enter-

prise SOA: service-oriented architecture best prac-

tices. Prentice Hall Professional.

Leymann, C. F. F., Retter, R., Schupeck, W., and Arbitter,

P. (2013). Cloud computing patterns.

Mell, P. and Grance, T. (2011). The nist deﬁnition of cloud

computing.

Menychtas, A. et al. (2013). Artist methodology and frame-

work: A novel approach for the migration of legacy

software on the cloud. In Symbolic and Numeric Algo-

rithms for Scientiﬁc Computing (SYNASC), 2013 15th

International Symposium on, pages 424–431. IEEE.

OCP (2014). Open city platform project. http://

www.opencityplatform.eu/.

OMG (2014). Mda. http://www.omg.org/mda/.

Parkhill, D. F. (1966). Challenge of the computer utility.

Rackspace (2014). http://www.rackspace.com/cloud/hybrid.

RedHat (2014). https://engage.redhat.com/forms/cloud-

readiness-assessment.

Remics (2014). Remics project. http://www.remics.eu/.

Vaquero, L. M., Rodero-Merino, L., Caceres, J., and Lind-

ner, M. (2008). A break in the clouds: towards a cloud

deﬁnition. ACM SIGCOMM Computer Communica-

tion Review, 39(1):50–55.

VmWare (2014). http://www.cloudﬂightcheck.com/.

Vu, Q. H. and Asal, R. (2012). Legacy application mi-

gration to the cloud: Practicability and methodology.

In Services (SERVICES), 2012 IEEE Eighth World

Congress on, pages 270–277. IEEE.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

126