Porting Non Cloud-native Applications across Linux Distributions: A

Practical Approach

Sanjeet Kumar

and Suvrojit Das

Department of CSE, NIT Durgapur, India

Keywords:

Linux, Cloud Computing, Application Portability, Workload Migration.

Abstract:

Researchers are trying to solve the problem of application portability ever since we had multiple types of Unix

operating systems. The need for a solution to port application between different operating environments has

only grown in recent years after the adoption of the cloud. The consumers of IT applications want the freedom

of choice when it comes to operating environment. They don’t want to be put in a vendor lock-in where they

are compelled to use one particular platform inspite of their dissatisfaction of service or availability of a better,

economic and more competitive alternative. Sometimes the provider of the operating environment goes out of

business or there are other reasons where porting of applications becomes a necessity. Linux being an open

source operating system gives the liberty to consumers to ﬁrst extensively test and use the applications on

a free distribution and later port it to a distribution with enterprise support. Portability of cloud native apps

are more or less solved by use of containerization tools and their ecosystem however the portability of non

cloud-native applications is still an open research problem. This paper provides the solution to the problem

of porting an application from one distribution of linux to another using an approach which can further be

generalized for porting of application between wider range of operating environments.

1 INTRODUCTION

According to leading industry analysts linux is the

fastest growing server operating system but the over-

all growth of combined server operating system mar-

ket is only 0.7% (Gartner, ) which implies that more

and more organizations are moving their applications

and workloads from proprietary operating systems to

linux. There is another perspective to this migra-

tion story, organizations wants to move away from

vendor lock-in. They want to use a platform that

gives them choice and freedom. Currently there are

atleast 4 linux vendors which provide enterprise sup-

port for linux viz SUSE, Red Hat, Oracle and Canon-

ical(Ubuntu). Apart from these there are some pretty

impressive community driven linux distributions like

openSUSE and CenOS which organizations with in-

ternal technical skills are adopting without enterprise

support.

Porting of application from one OS platform to

another OS platform is a very sophisticated task. It

needs lots of planning and very granular understand-

ing of the source and target platforms as well as un-

https://orcid.org/0000-0002-8755-8837

https://orcid.org/0000-0001-5414-5019

derstanding of the required dependencies of applica-

tion on its platform. Many applications are tightly

locked with their platform and require a lot of effort

in porting. Many standards that serve as a guide for

both OS providers as well as application developers,

guides them to provide the capabilities of porting of

application source and binary between the platforms

that conform to certain standards. Linux Standard

Base(LSB) is one such standard. Currently there are

about 20 different linux distributions which conforms

with LSB 5.0 set of speciﬁcations. Still, we see a

lot of deviations and porting an application from one

linux distribution to another distribution is still a very

challenging task.

Porting of applications and workloads between

different OS is a very old problem. The growth in

adoption of cloud as an infrastructure has only caused

this problem to multiply. Cloud brings much more

ﬂexibility than that of traditional virtualization infras-

tructure. Cloud has seen adoption in primarily two

types of use cases. One, in a large organization where

there are multiple departments or lines-of-business.

In such an organization there is a separate IT depart-

ment which serves all the IT infrastructure require-

ment of all the other departments. Second use case is

272

Kumar, S. and Das, S.

Porting Non Cloud-native Applications across Linux Distributions: A Practical Approach.

DOI: 10.5220/0011083700003200

In Proceedings of the 12th International Conference on Cloud Computing and Services Science (CLOSER 2022), pages 272-279

ISBN: 978-989-758-570-8; ISSN: 2184-5042

where a cloud service provider provides the necessary

infrastructure to a consumer who can be an individ-

ual or an organization. Traditionally the infrastructure

procurement itself used to take weeks, and now, with

self service in cloud, the line of business can instantly

utilize the infrastructure allocated to them from the

pooled resources. The applications can achieve very

high scalability as per the demand and load.

Porting of application between different types of

infrastructure has its own set of challenges. Standards

like Open Virtualization Format(OVF) from the Dis-

tributed Management Task Force(DMTF) has worked

in this area to make at least the virtual machine image

conform to a standard which eases out the process of

porting, however, porting from physical to cloud still

remains a challenge. There are some proprietary tools

which help with physical to virtual/cloud porting but

they have limitation that they provide solution primar-

ily for intel/amd based architecture.

The adoption of containerization tools like docker

and kubernetes has made the problem of linux appli-

cations look solvable. The applications can be mod-

iﬁed and made cloud native to be able to run on a

container infrastracture and then the porting o such

applications becomes very easy. However, just like

not all pets can be turned into cattles, similarly, not

all applications can be modiﬁed into cloud-native ap-

plications and therefore the research community has a

job to look into solution for portability of non cloud-

native applications.

For our experiment we took help of an open source

tool named machinery. Machinery is aimed at conﬁg-

uration discovery, system validation and service mi-

gration. Machinery is based on an idea of universal

system descriptor. Although, this project is in a very

nascent stage and currently the feature and function-

alities are very limited, the idea of universal system

descriptor should be valid for all kind of operating

system but the current implementation only focuses

on linux OS. The current implementation captures the

system description for rpm and deb family of linux

distributions. However, for the purpose of export-

ing the system description as a response ﬁle for au-

tomatic description, currently it only supports SUSE

and openSUSE and in one of our previous work (Ku-

mar and Das, 2021) we have contributed to the project

so that it can export the system-description of red-

hat family of linux distribution aswell. Secondly, al-

though it has a base prepared for porting of applica-

tion and services but the implementation for the same

has not been done.

We identiﬁed that this could be a very useful tool

for application portability use cases. Therefore, we

have began contributing to this project https://github

.com/ksanjeet/machinery/tree/port\ task and solved

the problem of portability of non cloud-native linux

application across linux distribution. In this paper we

are proving the concept using experimental setup and

based on our contribution to this project for portability

of non cloud-native application from one linux plat-

form to another linux platform.

This paper is further divided into a section on lit-

erature review where we have referenced theoretical

and experimental work on application portability in

general as well as in cloud since 1985 till now. In

next section we explain real life problems which be-

came our motivation for this work and our scope and

objectives that we want to achieve through this pa-

per. After that we are introducing our approach and

methodologies for this experimental work, the chal-

lenges we faced and the ideas and algorithms that we

used to overcome the challenges. In the next section

we discuss the results from our experiment and limi-

tations that we ﬁnd in our approach and what we can

do to remove these limitation in future work. Finally

we conclude our paper and explain how this work

can help in future research in application portability

in cloud.

2 LITERATURE REVIEW

Application portability was ﬁrst considered as a prob-

lem in mid 1980s when there were several variations

of Unix that ran on various hardware architecture.

Mooney (Mooney, 1990) deﬁnes application portabil-

ity as an application is portable across a class of en-

vironments to the degree that the effort required to

transport and adapt it to a new environment is less

than the effort of redevelopment.

In 1985 X/Open Portability Guide (Taylor, 1987)

was released which gave guidelines for a common

application environment(CAE) and served as a refer-

ence on creating application that can be ported across

operating systems.

In 1988 ISO/IEEE POSIX (Group, 1988)(Group,

2018) was released which had a limited scope of

source code portability across various conforming op-

erating systems.

Hankinson (Hankinson, 1990) writes from a US

govt federal agencies perspective that there was a

need to establish strategies and plans for acquiring

information technology products and services based

on open system standard which supports applica-

tion portability and interoperability. His organization,

National Institute of Science and Technology(NIST)

developed a standard called Open System Environ-

ment(OSE) towards this. Similarly Application Porta-

Porting Non Cloud-native Applications across Linux Distributions: A Practical Approach

273

bility Proﬁle(APP) which is an OSE standard proﬁle

was developed by NIST to deﬁne US federal agen-

cies requirement of application. This was probably

the ﬁrst instance when requirement of a software ap-

plication was deﬁned in the form of standard proﬁles,

an idea that ’ll later be seen in application portability

solutions and approaches for cloud systems.

After the growth in adoption of linux operating

system, The Linux Foundation drafted its ﬁrst version

of Linux Standard Base(LSB) (Foundation, b) in 2001

to develop and promote open standard and increase

compatibility among various distributions. LSB gave

guidelines for common libraries, commands, utilities,

runlevels, printing systems etc. It extensively adopted

guidelines from POSIX and in particular it incorpo-

rated Filesystem Hierarchy Standard(FHS) (Founda-

tion, a) that was published in 1994.

When virtualization in x86 machine grew adop-

tion of technology like VMware and XEN and later

KVM, researchers (Ribiere, 2008) saw virtualization

as an important tool for application portability. It was

during this time that Distributed Management Task

Force(DMTF) came up with a virtual machine im-

age standard called Open Virtualization Format(OVF)

(DMTF, 2017). Before this there were different im-

age formats like VMDK, VHD, VDI, etc. Now with a

common image format even if the source image was

something else it could be converted to either OVF or

OVA(open virtualization appliance) and could be im-

ported at the target virtual machine. This helped a lot

for the cause of application portability, however one

couldn’t port an image to a bare metal server,

With the growth in adoption of cloud infrastruc-

ture, researchers tried to ﬁnd the solution for the prob-

lem for application portability in this new kind of en-

vironment. Cretella and Martino (Cretella and Mar-

tino, 2012) suggested a method for automated analy-

sis of cloud vendors.

Research in application portability in cloud are fo-

cused in two levels of abstraction:

One, at a higher level of abstraction where stan-

dard proﬁles are created for application where the ca-

pabilities required by the application from the plat-

form is deﬁned in a descriptive language. The capa-

bilities of the platforms can be queried and a mapping

can be done whether application can run on a particu-

lar platform or not. For example, an application pro-

ﬁle might mention the requirement as an http server

running on port 80. This requirement can be fulﬁlled

by platform running either Apache, lighttpd or ng-

inx. This type of application portability research fo-

cuses more on cloud native applications, applications

with microservices architecture, applications that are

highly scalable in design.

Second type of research focuses on a slightly

lower level of abstraction where the application along

with its required dependencies is ported from one in-

frastructure to the other. The infrastructure here can

be Physical, virtual, containers or cloud. This type of

application portability research focuses more on ap-

plication with traditional monolithic and N-tier archi-

tecture.

Different researchers have suggested different ap-

proach to solve the problem of application portabil-

ity in cloud. Petcu et al (D. Petcu and Crciun, 2013)

solution creates a higher layer of abstraction which

abstracts different APIs of different cloud so that the

application ﬁnds a common API to work with. The

problem with this approach is that it is not useful

when a set of API is not covered under the abstrac-

tion layer of this solution.

OASIS provided a different approach, a standard

called TOSCA for portability and interoperable op-

erations on cloud applications. Binz et al (T. Binz

and Leymann, 2014) introduces TOSCA as a stan-

dard which provides new way to enable portable au-

tomated deployment and management of composite

applications, TOSCA uses a modeling language to

formalize the application structure as typed topology

graph. TOSCA has since been very popular with re-

searchers with implementation done by Katasaros et.

al. (G. Katsaros and Eberhardt, 2014) and Antoniades

et. al. (D. Antoniades and Kornmayer, 2015).

There are however other approaches or notable ex-

perimental work done by:

Gonidis reported an experimental work with dif-

ferent PaaS platforms. Munnisso demonstrates a

proof-of-concept for application portability of cloud

application that consumes restful APIs using an al-

gorithm for mapping the application to its cloud re-

source.

3 OBJECTIVE AND MOTIVATION

There are several use cases that are the objective of

this work like upgradation of an existing linux system,

moving of workload from physical/virtual to cloud,

regulatory and compliance requirements. However,

the main motivation is to ﬁnd a solution to avoid ven-

dor lock-in for a paid linux distribution. The linux

distributions like Amazon Linux, Canonical Linux,

Oracle Linux RHEL, SLES provides great services

and support to their customers but sometimes when

the consumer wants to port from one distro to another

there is no easy way to do that.

In december 2020 Redhat announced that they

will discontinue centOS in its original format used by

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

274

thousands of consumers running millions of servers

(RedHat, ) forcing them either use paid version of

RedHat or use a version that is of no use to them. This

was a real life situation which motivated us to build a

solution to port workloads from one linux distribution

to another. In this work we are demonstrating how the

above problem can be solved in an automated way.

4 METHODOLOGY

To port non cloud-native application from one linux

distribution to another we have used machinery tool

and developed additional features in this tool that

helps us to achieve the application portability. We had

to answer three questions in order to build our solu-

tion.

What Constitute an Application? A clear deﬁnition

of application is very necessary to perform its migra-

tion. What may be an application for one user may be

an Linux distribution feature or dependency for an-

other user. Deﬁning what is application is also neces-

sary as not every application comes in the packaging

format of the linux distribution package manager. For

example a python application may not have been in-

stalled by RPM or DEB and instead it may have been

installed by ”pip”. Similarly a ruby application may

have been installed by ”gem” instead of the distribu-

tion speciﬁc package manager. A tomcat or apache

applicaion may simply be a collection of ﬁles in their

document root. We have therefore arrived at follow-

ing deﬁnition that can be put into a program logic to

identify the application from the rest of the operating

system:

1. It has to be RPM package that is not part of the

base OS. Please see section 4.1.1 to see what we

have assumed as the base OS.

2. It has to be a ”pip” installed python application

3. It has to be a ”gem” installed ruby application

4. It has to be a ”npm” installed javascript applica-

tion

5. It has to be tomcat application stored in its stan-

dard document root as per its linux distribution

6. It has to be apache web application in its standard

document root as per its linux distribution.

Above deﬁnition is used for a working boundary

and it can be extended with additional criteria for in-

cluding more sets of applications.

How to Optimize Machinery System Descriptions

So That It only Captures the Application and Not

the Rest of the OS? To ﬁlter only the contents of

applications (rpm and other packages, conﬁguration,

managed and unmanaged ﬁles etc) we ﬁrst compare

the system descriptions of the source system and the

base of the source system. A base system is a plain

vanilla installation of that particular linux distribution

which doesn’t have installed on it. The comparsion

gives us a diff of the two system description. This is

further optimized to remove any distrubution speciﬁc

content and ﬁnally only the application related con-

tents are left. This is also explained in Algorithm 1.

How to Convert from Source System Description

to Target i. e. RPM Names etc? In different linux

distributions the names of many packages are dif-

ferent. Even for the distributions using same pack-

age manager for example centOS and openSUSE uses

RPM package manager the names of the package re-

lated to apache web servers are different. On Cen-

tOS the name for apache web server is ”httpd” while

on openSUSE it is ”apache2”. There are many many

more packages that have different names. Our method

for conersion involves using tools like ”zypper” and

”dnf” to match the binaries and libraries from the tar-

get distribution repository. Once the match is found

then the system description content is replaced ac-

cordingly from source content to target content.

4.1 Experiment: Portability of

Application from One Linux

Platform to Another Linux Platform

Automated porting of application from linux distribu-

tion to another is a big challenge. We have chosen one

distro of RedHat family as the source and one distro

of SUSE family as the target. There are many differ-

ence between the two distros such as software pack-

ages names are different in Red Hat family of Linux

and SUSE family of linux. Users and groups may

have different UIDs, GIDs. Conﬁguration ﬁles for

the same packages may have different locations for

these two families of linux. A simple free command

shows slightly different output when run on these two

ﬂavour of linux. Therefore an automated porting has

to be done very carefully.

4.1.1 Assumptions

To come up with an automated solution we have to

make a very basic assumption. The assumption is

that a minimal OS installation of these two ﬂavours

are equal. By minimal installation we mean only

OS has been installed without any additional appli-

cation server or database services installation. More

granularly, a minimal installation is: Linux Standard

Base(LSB), X-Window environment, Gnome or KDE

desktop environment, other basic utilities to provide

Porting Non Cloud-native Applications across Linux Distributions: A Practical Approach

275

Algorithm 1: Port system description of one version or distribution type to another version or distribution type.

Command=”port”, argument1=”sname” (for source name), argument2=”tname” (for target name)

Legends:

← = assignment, <action> direction

: = action

:: = derives subclass

.function(arg) = executes function using argument arg

1: ”dsname” ← system description(sname)

2: ”sbase” ← name(Search : {OS,architecture} ← source)

3: ”dsbase” ← system description(Search : {OS,architecture} ← source)

4: Input : target ← choices

5: ”tbase” ← name(target)

6: ”dtbase” ← system description(target)

7: Machinery::PortTask.new()

8: Machinery::PortTask(sname, dsname, sbase, dsbase, tbase, dtbase, tname)

9: Create(Dir) : {name : tname, parent dir : DEFAU LT CONFIG DIR}

10: json

arse({sname,sbase,tbase})

11: ”s di f f ” ← ”dsname” − ”dsbase”

12: ”plist” ← r pm names(Run remote

ommand : sname(r pm − group : {”SystemEnvironment/Daemons”, ”Applications/Engineering”}))

13: c ← 0

14: l1 ← length o f array s di f f [”packages”][” elements”]

15: l2 ← length o f the array ”plist”

16: for i ∈ {1,.. .,l1 − 1} do

17: h ← hash o f s di f f [”packages”][” elements”][c]

18: name ← h[”name”]

19: if plist includesname? then

20: c=c+1

21: next i

22: else

23: delete h from s diff[”packages”][” elements”]

24: next i

25: end if

26: end for

27: ” f list” ← unmanaged f iles to be deleted f rom target

28: c ← 0

29: l1 ← length o f array s di f f [”unmanaged”][” elements”]

30: l2 ← length o f the array ” f list”

31: for i ∈ {1,.. .,l1 − 1} do

32: q ← 0

33: h ← hash o f s di f f [”unmanaged”][” elements”][c]

34: name ← h[”name”]

35: for j ∈ {1, . .., l2 − 1} do

36: if name starts with f list[ j]? then

37: s di f f [”unmanaged”][” elements”][h].delete()

38: next j

39: else

40: q ← 1

41: end if

42: end for

43:

44: if q = 0? then

45: c=c+1

46: next i

47: else

48: next i

49: end if

50: end for

51: for all s di f f [”packages”][” elements”] as s do

52: spname ← s[”name”]

53: ”t pname” ← Run remote command : ”tbase”(r pm name = ”spname”))

54: s[”version”] ← t pname[”version”]

55: s[”release”] ← ””

56: s[”arch”] ← t pname[”arch”]

57: s[”vendor”] ← t pname[”vendor”]

58: s[”cheksum”] ← ””

59: end for

60: tdes ← dtbase + s di f f

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

276

a graphical interface to user. It can also be under-

stood in this way that when we install RedHat/Cen-

tOS manually at one point it gives us a choice for soft-

ware selection. There if we choose server with GUI,

that is our deﬁnition of minimal. Similarly in case of

SUSE/OpenSUSE it gives a choice of interface during

manual installation and if we choose Gnome Environ-

ment, that is our minimal. The reason for choosing a

graphical environment in minimal system is that in

every practical installation we see graphical environ-

ment. If we do not chose a graphical environment

then our difference from this minimal system and our

source system which we want to port will be huge.

Figure 1: Conceptual Depiction of problem of linux appli-

cation portability

4.1.2 Settings

Now that we have deﬁned what is a minimal OS in-

stallation, we take a machinery system description of

this minimal system which will become our base sys-

tem description for reference and for calculating dif-

ference. Secondly we take a system description of our

source system. Lets suppose our source system is a

CentOS and we want to port it to openSUSE. We ﬁnd

out the difference between CentOS minimal and Cen-

tOS source by compare command of the machinery

tool and store it into a ﬁle.

Now, we had to create another script which will

read the content of this ”diff” ﬁle and check from the

rpm package ﬁle list which are the equivalent rpm

packages containing the same binaries and libraries

and then substitute those rpm names with equivalent

names of the target system. In this experiment’s case

openSUSE system.

d e s c ”Move s y s t e m d e s c r i p t i o n ”

l o n g d e s c <<−LONGDESC

Move a s y s t e m d e s c r i p t i o n .

The s y s t em d e s c r i p t i o n name i s

→ cha ng ed t o t h e p r o v i d e d

→ name .

LONGDESC

a r g ”FROM NAME”

a r g ”TO NAME”

command ”move ” do | c |

c . a c t i o n do | g l o b a l o p t i o n s ,

→ o p t i o n s , a r g s |

from = s h i f t a r g ( a r g s , ”

→ FROM NAME” )

t o = s h i f t a r g ( a r g s

→ , ”TO NAME” )

t a s k = MoveTask . new

t a s k . move (

→ s y s t e m d e s c r i p t i o n s t o r e ,

→ from , t o )

end

d e s c ” P o r t Syst e m D e s c r i p t i o n ”

l o n g d e s c <<−LONGDESC

P o r t a s y s t e m d e s c r i p t i o n .

The s o u r c e s y st e m d e s c r i p t i o n i s

→ p o r t e d t o t a r g e t l i n u x

→ p l a t f o r m ( e . g . CentOS −>

→ openSUSE )

LONGDESC

a r g ”SOURCE NAME”

a r g ”SOURCE BASE”

a r g ”TARGET BASE”

a r g ”TARGET NAME”

command ” p o r t ” do | c |

c . a c t i o n do | g l o b a l o p t i o n s ,

→ o p t i o n s , a r g s |

sname = s h i f t a r g ( a r g s , ”

→ SOURCE NAME” )

dsname = S y s t e m D e s c r i p t i o n . l o a d

→ ( sname ,

→ s y s t e m d e s c r i p t i o n s t o r e )

s b a s e = s h i f t a r g ( a r g s , ”

→ SOURCE BASE ” )

d s b a s e = S y s t e m D e s c r i p t i o n . l o a d

→ ( s b a s e ,

→ s y s t e m d e s c r i p t i o n s t o r e )

t b a s e = s h i f t a r g ( a r g s , ”

→ TARGET BASE ” )

d t b a s e = S y s t e m D e s c r i p t i o n . l o a d

→ ( t b a s e ,

→ s y s t e m d e s c r i p t i o n s t o r e )

tname = s h i f t a r g ( a r gs , ”

→ TARGET NAME” )

t a s k = P o r t T a s k . new

t a s k . p o r t ( sname , dsname , sb a s e ,

→ d s ba s e , t b a s e , d t b a s e ,

→ tname )

end

d e s c ” Depl o y image t o O pen S tac k

→ c l o u d ”

l o n g d e s c <<−LONGDESC

Porting Non Cloud-native Applications across Linux Distributions: A Practical Approach

277

Once the conversion of the diff or extra system

description is complete we can add this diff or extra

system description to the base or minimal install of

the target distribution and then export the ﬁnal system

description as either autoyast proﬁle if the target dis-

tribution belongs to SUSE family or as kickstart pro-

ﬁle if the target distribution belongs to RedHat fam-

ily. Since in our experiment’s the target distribution

is openSUSE therefore we exported the ﬁnal system

description as autoyast proﬁle. These autoyast/kick-

start proﬁle are further used to build a deployable ISO

image which can be used to deploy on the target in-

frastructure which can be physical, virtual or cloud.

Figure 2: Conceptual Depiction of solution of linux appli-

cation portability.

5 RESULT AND FUTURE WORK

This experiment is a proof-of-concept that non cloud-

native applications and services can be ported be-

tween different ﬂavours of linux. We were able to

improve the capabilities of the machinery tool in a

way that it can be used for porting of whole appli-

cation workloads from one operating environment to

another.

Table 1: Results of contribution in Machinery tool.

S.No. Features Before

Contri-

bution

After

Contri-

bution

1 Inspect system and cre-

ate system description

Yes Yes

2 Compare two system

descriptions

Yes Yes

3 Store difference after

comparison

No Yes

4 Convert difference to

the equivalent of target

linux distro

No Yes

5 Apply the difference to

a target base system de-

scription

No Yes

6 Export system descrip-

tion to a autoinstall pro-

ﬁle

Only

Autoy-

ast

Autoyast

and

Kick-

start

Successful application portability requires support

both from the infrastructure as well as applications.

While working on this we realised that the challenge

of identifying the application layer of software or the

software or services that needs to be ported can be

solved a small information is added to the rpm pack-

ages, therefore, we recommend that porting of linux

applications can become easier if while creating rpms

of applications we set a portable ﬂag in the rpm infor-

mation e.g. instead of rpm-group name System Envi-

ronment/Daemon we may give the rpm-group name

as System Environment/Daemon:Portable so that it

can easily be identiﬁed as an rpm package that can

easily be ported to a new version or a different linux

distribution.

We made several enhancement to the original

machinery tools to achieve the target of application

portability. Here is a list of contributions done.

In the enterprise segment the type of operating

systems used as platform for hosting applications are

very few. Apart from linux, which is the most grow-

ing operating system, windows and unix ﬂavours like

HP UX, IBM AIX and Solaris are the only other op-

erating systems that are predominantly used.

REFERENCES

Cretella, G. and Martino, B. D. (2012). Towards automatic

analysis of cloud vendors apis for supporting cloud

application portability. 375:61–67.

D. Antoniades, N. Loulloudes, A. F. C. S. D. T. G. P. M. D.

and Kornmayer, H. (2015). Enabling cloud applica-

tion portability, proceedings of the 8th international

conference on utility and cloud computing. pages

354–360.

CLOSER 2022 - 12th International Conference on Cloud Computing and Services Science

278

D. Petcu, G. Macariu, S. P. and Crciun, C. (2013).

Portable cloud applications-from theory to practice.

29(6):1417–1430.

DMTF (2017). Information technology open virtualization

format (ovf) speciﬁcation. pages 1–61.

Foundation, T. L. Filesystem hierarchy standard (fhs). http

s://refspecs.linuxfoundation.org/FHS3.0/fhs-3.0.pdf.

last accessed: Dec 24, 2021.

Foundation, T. L. Linux standard base (lsb). https://wiki.l

inuxfoundation.org/lsb/start. last accessed: Dec 24,

2021.

G. Katsaros, M. Menzel, A. L. J. R. R. R. S. and Eberhardt,

J. (2014). Cloud application portability with tosca,

chef and openstack. 302:295–385.

Gartner. Gartner market share analysis server operating sys-

tem, worldwide 2016. https://www.gartner.com/doc/

3731017/market-share- analysis-server-operating.

last accessed: Oct 20, 2020.

Group, P. (1988). Ieee standard portable operating system

interface for computer environments. pages 1–40.

Group, P. (2018). Ieee standard for information tech-

nology–portable operating system interface (posix(r))

base speciﬁcations. pages 1–3951.

Hankinson, A. (1990). Open system standards: A us gov-

ernment perspective. 10:207–211.

Kumar, S. and Das, S. (2021). An open source and practi-

cal approach to x2x linux workload migration. page

1791–1796.

Mooney, J. (1990). Strategies for supporting application

portability. Computer, 23(11):59–70.

RedHat. Centos stream: Building an innovative future for

enterprise linux. https://www.redhat.com/en/blog/cen

tos-stream-building-innovative-future-enterprise-lin

ux. last accessed: Jan 16, 2022.

Ribiere, A. (2008). Using virtualization to improve dura-

bility and portability of industrial applications. pages

1545–1550.

T. Binz, U. Breitenbcher, O. K. and Leymann, F. (2014).

Tosca: Portable automated deployment and manage-

ment of cloud applications.

Taylor, C. (1987). The x/open group and the common ap-

plication environment. 5(4):665 – 679.

Porting Non Cloud-native Applications across Linux Distributions: A Practical Approach

279