A template for the arxiv styleA SURVEY AND COMPARATIVE STUDY ON
MULTI-CLOUD ARCHITECTURES: EMERGING ISSUES AND CHALLENGES FOR
CLOUD FEDERATION
A PREPRINT
[email protected]
[email protected]
National Institute of Technology Kurukshetra, India
[email protected]
ABSTRACT
Multi-cloud concept has broaden the world of cloud computing and
has become a buzzword today. The word “Multi-cloud” envisions
utilization of services from multiple heterogeneous cloud providers
via a single architecture at customer (e.g. organization) premises.
Though cloud computing has many issues and offers open research
challenges, still the academics and industrial research has paved a
pathway for multi-cloud environment. The concept of multi-cloud is
in maturing phase, and many research projects are in progress to
provide a multi-cloud architecture which is successfully enabled in
all the respects (like easy configuration, security, management
etc.). In this paper, concepts, challenges, requirement and future
directions for multi-cloud environment are discussed. A survey of
existing approaches and solutions provided by different multi-cloud
architectures is entailed along with analysis of the pros and cons
of different architectures while comparing the same.
Keywords cloud broker · cloud federation · inter-operable ·
multi-cloud.
1 Introduction
Cloud computation world is transforming in anticipation and is
rightly contributing in successful technical progress of almost
every organization across the world [1], [2], [3], [4]. From
economic point of view, cloud computing represents a business model
for renting software and hardware resources [5], [6], [7], [8].
Multi-Cloud has extremely attracted the corporate world. EMA
surveyed 260 enterprises and majority of the respondents i.e., 61%
reported using two or more public cloud provider. All of us are
familiar with the fact that the amount of useful information
produced by an organization today in one day is approximately equal
to the amount of information produced in twenty days earlier a
couple of decades back [9], [10], [11], [12], [13]. Single cloud
framework is not suitable and has become insufficient to serve the
ever growing requirement [14], [15], [16], [17]. Seeing the current
trend of computational growth in organizations, it is quiet obvious
that future is multi-cloud.
∗The authors would like to thank National Institute of Technology
Kurukshetra, India for financially supporting this research
work.
ar X
iv :2
10 8.
12 83
1v 1
1.1 Multi-cloud concept
With the advent of cloud, small and big organizations all are
progressing without need to concern about the storage and
maintenance of their business data. They are not required to spend
in billions for the same. All the responsibility is envisaged upon
the cloud service providers (CSPs) [18], [19], [20]. So, cloud
computing has become the backbone of modern business world.
Organizations contacts various cloud service providers and consumes
the services by signing Service-Layer Agreement SLA document [21],
[22], [23], [24], [25]. A CSP contacts various resource providers
at datacenters in order to satisfy the demands of the customer
[26], [27], [28], [29]. Usually, it is said that cloud computing
provides infinite resources and elastic services [30], [31].
Practically, we know that resources cannot be infinite at any
datacenter. To raise the elasticity or capacity of cloud service
providers and fulfill the ever growing demand of services,
resources from different resource providers need to collaborate,
inter-communicate and work in cooperation and coordination. So,
collaboration of various cloud service providers gives root to the
concept of Multi-Cloud. Multi-cloud simply means an enterprise can
take services from more than one cloud service provider through a
common interface or a single API. In multi-cloud environment,
multiple cloud providers aggregate in a single pool to provide
three basic services of cloud: computation, storage and networking.
Computation service allows customers to instantiate their own
computational nodes irrespective of their physical server node at
different datacenters. Storage service enables users to store
infinite data as per they desire without vendor- lock-in. They can
store public data at public cloud and confidential data at private
cloud
1.2 Vendor lock-in
In Single cloud environment, security of user data is completely in
the hands of the cloud provider and he leverages entire control of
user data. This situation represents “vendor lock-in” drives user
data towards potential security risks. To resolve this issue,
multi- cloud approach provides appropriate solution. Networking
provides communication between computational and storage nodes
despite of the networking infrastructure hosted upon physical
connectivity between actual physical servers. Multi-cloud allows
user to organize, transfer, synchronize and manage sharing of files
between cloud storage services like Dropbox, Google Drive, Copy,
OneDrive, FTP, WebDav, MEGA, etc. 26 cloud drives supported so far
[20].
1.3 Challenges of Multi-Cloud
• API’s differ: Different sets of resources are there, different
formats and encodings, and several simultaneous versions of single
cloud exist.
• Abstractions differ: Network architecture differ- VLANs, topology
differ, addressing grounds differ.
• Difference in storage architecture- local/attachable, disks and
backups.
• Hypervisor and machine configuration differ etc.
• Mismatch of cyber-laws of various interconnected clouds depending
on their geographical location physically.
• Interoperability of different cloud providers always a major
issue for multi-cloud set-up.
• Difficult to tackle the security challenges related to multi-
provider environment.
• Different cloud provider follows their own management scheme for
load balancing and monetization features.
Interoperability: The biggest challenge in cloud computing is the
diversity of resources, management and rules and regulations of
cloud providers, diverse SLAs, differences in security
characteristics at various CSPs etc. Interoperability means the
ability of diverse system to work in cooperation and serve the
common output. Interoperability of multi-cloud has several
heterogeneous dimensions:
• Vertical interoperability Along the cloud stack, interoperability
increases as we move from IaaS to SaaS. To deal with such
heterogeneity, standardize platform and mapping interface layers
are required.
• Horizontal interoperability The inter-communication issues lying
between various service providers, techni- cally, physically,
logically and legally etc. while contributing for
multi-cloud.
Across the world, thousands of data centers are geographically
distributed which vary in cost of electrical consumption. At
various data centers, there exist heterogeneity in resource usage
there logical and physical infrastructure. Each different CSP
follows his own SLA policies, management rules, security features,
cloud service cost etc. In order to deal with the above challenges,
various inter-cloud or federated cloud approaches were proposed.
Many projects are in progress to set-up multi-cloud architecture.
In this paper, number of multi-cloud or federated cloud or
inter-cloud approaches are surveyed.
2
1.4 Organization
The remainder of this paper is as follows: Section1 introduces
concept of multi-cloud and challenges of multi-cloud. Section 2
gives detailed architectures of various cloud federation available
till now. Section 3 provides critical analysis on various
architectures discussed in this paper. Section 4 concludes the
paper and highlights the future scope.
2 ARCHITECTURAL VIEWS OF MULTI-CLOUD
2.1 CHARM
In the paper [32], (Quanlu Zhang et.al,2015) have presented “CHARM:
A Cost-Efficient Multi-Cloud Data Hosting Scheme with High
Availability”. Figure 1 shows the basic principle of multi-cloud
data hosting. Here the basic principle of data hosting on
multi-cloud is to distribute data across multiple clouds to gain
redundancy and prevent vendor-lock-in. The key component in this
model is “Proxy” which redirects the request from client
application and coordinate data distribution among multiple clouds.
Different clouds exhibit huge difference in terms of their services
like pricing policies and work performance. For instance, Google
cloud platform charges more for bandwidth consumption but Amazon S3
charges more for storage space and Rackspace provides all web
operations free via series of REST ful APIs. In this paper, in
order to reduce monetary cost and guaranteed availability, two
redundancy schemes are combined- replication and erasure coding.
The advantage of the CHARM multi- cloud model is that it provides
guidance to the customers to distribute their data on multiple
clouds in cost effective manner. CHARM makes fine-grained decisions
about which storage mode to use and which clouds to place data
in.
Figure 1: Basic principle of multi-cloud data hosting
2.2 OPTIMIS Cloud Federation
OPTIMIS cloud federation [33] have presented toolkit regarding
cloud service and cloud provider is presented. This toolkit can
optimize the whole service life cycle of cloud including service
construction, deployment, and operation on basis of aspects such as
trust, risk, eco-efficiency and cost. Several architecture of cloud
are also addressed in this paper. More significantly, two
architecture of cloud are discussed here.
• Federated Cloud: In this architecture, service provider (SP)
takes services from a single infrastructure provider (IP) , but,
one infrastructure Provider(IP) can sub-contract (or can lease some
services) with another IP , in order to raise the capacity,
elasticity and fault tolerance of cloud service.
• Multi-provider hosting: In this architecture, Service Provider
(SP), directly negotiates with more than one infrastructure
providers, to deploy services, monitors their operation and
migrates services from misbehaving IPs to maintain trust
relationship.
2.3 Multi-Cloud Brokering Architecture
In this type of architecture, a third party broker aggregates
services from multiple infrastructure providers (IPs) and delivers
these services to the actual service provider. The broker act as SP
for multiple IPs and it behave as IP for the SP. This model
simplifies the complexities of taking services from several
different IPs. Here, the broker provides single entry point to many
IPs and more fruitful is that the broker can get bulk of discount
from IPs from economic point of view. Moreover, in terms of
business policies have to make long term relation with the broker
for excellent growth of his business. Hence, risk and trust
prediction becomes easier with broker in between IPs and SP.
3
2.4 RESERVOIR MODEL
Rochwerger et al., 2009 [34] have introduced Reservoir model for
federated cloud computing. According to this architecture,
different infrastructure provider (IP) can aggregate to provide
flexible and scalable cloud computing services as shown in figure
2. Here, IPs own the computational resources, network resources and
storage resources in an infinite pool. Service providers are the
agents who offers computational and storage services to the
customers with help of IPs resources at back end. In Reservoir
model, IPs and SPs are clearly separated. IPs operates reservoir
sites that actually owns and manages resources. The reservoir sites
collaborates to form a Reservoir Cloud. Virtualization layer is set
up for separation of different Virtual Execution Environment (VEEs)
and the resource usage optimization at each reservoir site. Service
applications of customers are deployed on reservoir cloud using
service manifest, on one or more VEE as per the requirement.
Service manifest will give information regarding capacity of
physical infrastructure such as the number of VEEs that can be
hosted on a CPU, structure of service application in terms of
software stack (OS, middleware, application, data and
configuration). Service manifest also indicates Key Performance
Indicators (KPI). KPI measures load parameters, response time,
throughput, number of active sessions and resource allocations i.e.
memory, bandwidth, number of VEEs. To resolve interoperability
issues, this model provides VEE management interface that supports
VEEM-to-VEEM communication. The broad limitation of this model is
that it has not mentioned any security issues handling while
collaborating various IPs in reservoir cloud. The practical
implementation of this reservoir model is not given.
Figure 2: Conceptual view of Reservoir Model of cloud
federation
2.5 Federated Cloud Management (FCM)
In FCM [35], several Infrastructure Providers exclusively dedicate
their computing infrastructure to a single cloud broker. Figure 3
shows FCM architecture where, various cloud brokers collaborates to
provide federated cloud environment. In FCM, interoperability is
resolved by enabling two levels of brokering.
• User service call is submitted to Generic Meta –Broker Service
(GMBS). • This call is then forwarded to selected Federated Cloud
Broker, which further selects VM from underlying
infrastructure provider for actual execution of service. FCM
incorporates high level brokering for cloud federation and on
demand automated service deployments. FCM Repository maintains all
the required information about virtual appliances at cloud broker
level.
Figure 3: FCM Architecture
2.6 Distributed Management Task Force (DMTF) Architecture
Cloud, & Incubator [36] have presented Distributed Management
Task Force (DMTF) Open Cloud standards Incubator models for
enabling interoperability in multi-cloud environment. According to
DMTF, three different models for supporting federated cloud
scenario have been identified. Datacenter includes Service
Providers (SP) and infrastructure provider (IP). The three models
differs in the working style of datacenters as follows:
• Firstly, at the datacenter, service provider can act as cloud
broker or an agent to federate underlying infras- tructure provider
resources and make the services available to the overlying
customers as shown in figure 4.
Figure 4: First case for cloud federation according to DMTF
approach
• 2. In second case, multi-cloud model is presented, where
datacenter can request services from various infrastructure or
resource providers, thus they support different SLA’s parameters.
Figure 5 shows this scenario.
Figure 5: Second case for cloud federation according to DMTF
approach
• In third case, if a datacenter is served by one SP and hosted by
one IP overflows the available computing capacity limit, then
another infrastructure provider can contribute extra computing
capacity for the former IP. But, Service Provider is unaware of
this resource provisioning.
2.7 Contrail Architecture
Carlini et al. [37] introduced Open Contrail Architecture for cloud
federation. The goal of Open Contrail project is to minimize the
burden on user and increase efficiency of the cloud platform, by
performing horizontal ( resolving interoperability issues in cloud
federation) and vertical (providing cloud federation facility at
cloud stack level i.e. IaaS and PaaS services) integration. This
architecture utilizes the resources of various cloud resource
providers, regardless of the heterogeneity of underlying
infrastructure. Complete open source approach is adopted here. It
also supports user authentication, integration of SLA management
and application deployment. Contrail architecture has three layer
to support federation of clouds. Figure 6 shows Open Contrail
Federation:
5
Survey on Multi-Cloud Architectures A PREPRINT
• Interface Layer: This is top most layer, which provides
interaction between user and contrail federation. It consists of
REST API, http and Command Line Interface.
• Core Layer: This is middle layer, which contains various modules
to provide functional requirements like application life-cycle
management and non-functional like security requirements.
• Adapter Layer: This is bottom layer of the architecture, that
contains modules to retrieve information and operate on different
cloud resource providers. It copes with the heterogeneity of
underlying infrastructure.
Figure 6: Contrail Cloud Federation
2.8 Combinatorial Auction based Collaborative Cloud
Zhang, Li and Zhu, 2015 [38] have presented a Combinatorial
Auction- Based Collaborative Cloud Services Platform in the form of
model for cloud collaboration considering cost of communication and
negotiation among clouds under collaboration. This market model for
cloud collaboration includes three distinct layers as shown in
figure 7. First, user layer receives requests from end-user.
Second, Auction-layer matches requests with cloud services provided
by CSP. Third, CSP-Layer forms coalition to improve serving ability
to satisfy demands of the user. For coalition formation and to find
suitable partner for collaboration, Breadth Traversal Algorithm
(BTA) and Revised Ant Colony Algorithm (RACA) are introduced. Here
CSPs dynamically collaborate with one another and submit their
group’s bid as a single bid to the auction-layer. Whenever a
request is generated by the user, at user-layer, BTA and RACA
algorithm executes at auction-layer, for the selection of CSP to
enable dynamic collaboration of cloud to fulfill the request of the
user. The results presented with this model are not tested with
real-time data so it is somewhat unacceptable model.
Figure 7: Auction-Based Collaborative Cloud
2.9 Layered Multi-Cloud Architecture
Villegas et al. [39] have shown a layered multi-cloud architecture
by creating federation at each service layer as shown in figure 8.
At each layer, broker is present, who follows some pre-defined
collaboration terms for successful inter-cloud federation. They
have added federation of cloud model by showing how it works in
delivering Weather Research Forecasting (WRF). They have given
conceptual view of decoupling SaaS, PaaS and IaaS clouds. For such
federation, well defined policies and protocols must be defined.
PaaS layer act as middleware and act as a bridge for vertical
integration. It is a bridge between application and elastic
infrastructure resource management.
2.10 mOSAIC Multi-Cloud Architecture
Petcu et al. [40] have introduced Open-source API and Platform for
Multiple Clouds (mOSAIC). This project provides solution for
application portability and interoperability across multiple
clouds. It offers a middleware for deployment of multi-cloud
application. mOSAIC also handles the problem of changing of cloud
vendors. Here, application instance runs in mOSAIC component
getting access through dedicated APIs. Communication among its
components takes place through message queues. E.g. AMQP. Cloud
Agency of mOSAIC is a service for deployment of cloud applications.
Here Cloud Agency handles interoperability problem by introducing a
uniform interface for accessing multiple clouds. As shown in figure
9, mOSAIC model has provision for :
6
-application portability between clouds via set of APIs. -Support
dynamic negotiations with multiple cloud providers using brokering
system. -user-centric SLA.
Figure 9: mOSAI Cloud model
2.11 EGI FEDERATED CLOUD
EGI Federated cloud [41] integrates public, private or hybrid cloud
in the form of multi-national cloud system. Each resource center
operates cloud management framework (CMF) according to its own
preferences and then joins Federation and Collaboration services .
User can access all services of cloud federation with a single
identity.
2.12 CONTAINER TECHNOLOGY
Containers [42] have replaced traditional hypervisor based Virtual
machines. All most every top company like Microsoft, Facebook,
Google are using Docker Swarm or Kubernetes technology. Basically,
containers provide easy to deploy and secure orchestration of
specific self-contained virtual infrastructure. Cloud containers
can virtualize single application environment. Containers create an
isolation boundary at application level rather than at server level
.Isolation ensures that if anything goes wrong in a container, then
it may not effect another container deployed on same VM or server.
In absence of container, VM requires complete operating system to
be installed, but with container technology neither requires
complete installation of operating system nor even they requires
complete virtual copy of host server’s hardware resources.
Containers only requires software , libraries and basics of an
operating system and cloud containers can be very easily copied and
deployed on another server very easily.The only limitation of
containers is their management. Containers splits the
virtualization into smaller chunks, that creates difficulty in
management.[17].
2.13 SPINNAKER
Spinnaker [43] is an open source ,multi-cloud delivery platform. It
provides two important features : 1. Cluster management 2.
Deployment management. Cluster management: User can manage
resources in the cloud cluster which is a logical grouping of
servers in spinnaker. The logical grouping is based on user
application. Server groups defines the deployable artifacts i.e. VM
image, Docker image, source location. Deployment management: The
key feature of spinnaker are pipelines. Pipelines consists of
sequence of actions (like deploy, resize, disable, manual judgement
etc.) known as stages.
7
2.14 CLOUD FOUNDRY
Cloud Foundry [44] provides a standardized platform to the
applications of customers by decoupling the application from its
infrastructure. To enable this, CF offers two types of VMs: the
component VMs as platform infrastructure and the host VMs that host
applications for outside world. Hence, the organizations can make a
business decision on where to deploy workloads i.e. on premise, in
managed infrastructure or in public cloud.
2.15 SUPER CLOUD PROJECT
This project (Lacoste et al. [45]) has divided multi-cloud
architecture into three layers: data, compute and network layer.
This work focus on user-centric vision of cloud i.e. virtual
private cloud (VPC) just like VPN, inspite of usual
provider-centric cloud. To deal with interoperability issues, a
resource distribution layer i.e. SUPERCLOUD has been introduced.
VPC are set up in the form of U-Clouds consisting of data units,
compute unit and network units. These U-Clouds are VPC set upon top
of various cloud service providers. For security, they have
introduced shared data encryption and middleware-based encryption
and decryption of data. Figure 10, shows deployment architecture of
SUPERCLOUD project work.
• Compute Plane: This is topmost plane which applies nested
virtualization for abstracting computational resources of various
CSPs. Here, user can run several virtual execution environment
like, containers and virtual machines. This plane ensures proper
execution and protection of each user VMs. These VMs at compute
plane are deployed over user-hypervisor layer, which itself is
set-upon provider’s hypervisor.
• Data Plane: This plane manages all the storage management
responsibility and provides data management APIs for every
execution environment on the compute plane.In order to get access
to the cloud’s storage, a user’s compute VM realizes data
management VM as a proxy to get access to the cloud data.
• Network Plane: The network management is a network virtualization
platform based on Software-Defined Network (SDN).Here, the host VM
sends request to the network management VM to get direct access to
the storage data. This plane enables isolation between multiple
tenants by providing abstraction for network topology and traffic
routing.
Figure 10: SUPERCLOUD Architecture
2.16 Utility-oriented Federation of Cloud Environment
Buyya et al. [46] have proposed inter-cloud framework which
supports scaling of applications across multiple vendor clouds. In
this inter-cloud model, as shown in figure 11, every client in
federated environment needs to contact cloud brokering service that
can dynamically establish service contracts with cloud coordinators
through trading functions exposed by cloud Exchange. Cloud
Coordinators- They caters the deployment and management
responsibility for domain specific enterprise clouds and their
membership to overall federation driven by market-based trading and
negotiation protocols. Also, sensor infrastructure will monitor the
power consumption, heat dissipation, utilization of computational
nodes in virtual cloud environment. Cloud Broker finds out suitable
Cloud service provider through cloud exchange and negotiates with
cloud coordinators for resource allocation. Cloud Exchange keeps
information about cloud’s current usage cost and demand patterns.
In the end, it is concluded that federated cloud service gives
better performance than existing non-federated cloud
approaches.
8
Figure 11: Utility based Federated Cloud Model
Table 1 entails the summary and comparative analysis of
aforementioned multi-cloud architectures.
After analyzing various models of multi-cloud set-up reveals that
most of the work done in this regard( taking services from multi-
cloud) handles only interoperability issues and lacks concern for
trust and security management while collaborating. Also, much of
the research is limited upto theoretical concept of joining
multiple clouds together by having some Broker service between
various infrastructure providers and service providers. Still in
our opinion, SUPERCLOUD project model is most suitable among the
various available multi-cloud architectures till now. This is
because, it has covered almost every concerned feature for enabling
successful set- up of multi-cloud.
3 Conclusion and Future Directions
Single-cloud services are not suitable to meet the ever growing and
variety of demands of the organization. Hence, more effective way
is to employ multiple clouds to serve an organization. Every data
cannot be treated with‘equal status. As some data may be more
confidential than other, and some data will be completely public
for the advertisement. Hence according to the security requirement
, cost and official management of different data, it can be placed
on different appropriate clouds as per the suitability of the
organization. But to take services from multiple clouds is quiet
complex as you have to individually deal with multiple cloud
service providers. So, its better if there would be some unified
platform from where can access services of multiple clouds-
Multi-cloud infrastructure. To set-up multi-cloud, their exists
lots of complex issues- like interoperability, monetizing, security
management issues etc. In order to deal with these issues many
researchers from academic as well as industrial background have
provided solutions in the form of federated cloud or multi-cloud
architectures. In this paper, we have presented analytical review
of various multi-cloud architectures and also we have given
comparative analysis in the form of pros and cons of each
architecture. Finally, we have concluded that in our view,
SUPERCLOUD project model is at the top among all the existing
multi-cloud architecture concepts. But this project is in progress
and it is not fully implemented work.
References
[1] S. Deepika and S. A. Kumar, “A proactive autoscaling and
energy-efficient vm allocation framework using online
multi-resource neural network for cloud data center,”
Neurocomputing, vol. 426, pp. 248–264, 2021.
[2] D. Saxena and A. K. Singh, “Communication cost aware resource
efficient load balancing (care-lb) framework for cloud datacenter,”
Recent Advances in Computer Science and Communications, vol. 12,
pp. 1–00, 2020.
[3] D. Saxena, K. S. Vaisla, and M. S. Rauthan, “Abstract model of
trusted and secure middleware framework for multi-cloud
environment,” in International Conference on Advanced Informatics
for Computing Research. Springer, 2018, pp. 469–479.
[4] D. Saxena, I. Gupta, J. Kumar, A. Singh, and W. Xiaoqing, “A
secure and multi-objective virtual machine placement framework for
cloud data center,” IEEE Systems Journal, 2021.
[5] A. K. Singh and D. Saxena, “A cryptography and machine learning
based authentication for secure data-sharing in federated cloud
services environment,” Journal of Applied Security Research, pp.
1–24, 2021.
[6] A. K. Singh, D. Saxena, J. Kumar, and V. Gupta, “A quantum
approach towards the adaptive prediction of cloud workloads,” IEEE
Transactions on Parallel and Distributed Systems, 2021.
9
Table 1: Comparative Summary of Multi-cloud Architectures
Model, Author Aim Conceptual Approach Strength Weakness CHARM
(Zhang et.al, 2015) [32]
Cost-efficient multi-cloud data host- ing scheme with high
availability
“Proxy” redirects the re- quest from client applica- tion and
coordinate data distribution among mul- tiple clouds. In or- der to
reduce monetary cost and guaranteed avail- ability, two redundancy
schemes are combined- replication and erasure coding
It provides guidance to the customers to dis- tribute their data on
mul- tiple clouds in cost effec- tive manner
Various issues regarding cloud computing are un- covered like,
Manage- ment of multi- cloud, load-balancing, security etc.
OPTIMIS CLOUD FEDER- ATION (Ferrer et al., 2012) [33]
To provide toolkit to optimize whole service lifecycle as a
cloud
Service Provider (SP), directly negotiates with more than one
infras- tructure providers, to de- ploy services. a third party
broker aggregates services from multiple infrastructure providers
(IPs) and delivers these services to the actual ser- vice
provider
This model simplifies the complexities of taking services from
several dif- ferent IPs. The bro- ker provides single entry point
to many IPs and more fruitful is that the broker can get bulk of
dis- count from IPs from eco- nomic point of view
Only conceptual archi- tecture of several multi- cloud or federated
ap- proach architecture are given , but exact practi- cal
implementation is not given. How to handle interoperability issues
is not focused clearly
DISTRIBUTED MANAGE- MENT TASK FORCE (DMTF) ARCHITEC- TURE (Paper et
al., 2009) [36]
Open Cloud standards Incubator models for enabling inter-
operability in multi-cloud environment.
service provider can act as cloud broker to ag- gregate services
from in- frastructure provider and make them available to the
customers. Different IPs can collaborate to pro- vide services to
one ser- vice provider.
They have conceptually provided Incubator mod- els for handling
interoper- ability in multi-cloud en- vironment.
Service Provider is un- aware of this resource provisioning. So,
lack of reliability and trust. Secu- rity is major concern that is
not included here.
RESERVOIR MODEL (Rochwerger et al., 2009) [34]
Reservoir model for fed- erated cloud computing
Different infrastructure provider (IP) can aggre- gate to provide
flexible and scalable cloud com- puting services. Virtu- alization
layer is set up for separation of different Virtual Execution Envi-
ronment (VEEs) and the resource usage optimiza- tion at each
reservoir site
The resource usage opti- mization at each reservoir site.
Interoperability is handled by VEE manage- ment interface that sup-
ports VEEM-to-VEEM communication
Security, access feature, management of various multi-cloud
architecture are not discussed.The practical implementation of this
reservoir model is not given
LAYERED MULTI- CLOUD ARCHITEC- TURE (Villegas et al., 2012)
[39]
Layered multi- cloud architec- ture by creat- ing federation at
each service layer .
In layered multi-cloud ar- chitecture, at each layer, broker is
present, who follows some pre- de- fined collaboration terms for
successful inter-cloud federation.
They have given concep- tual view of decoupling SaaS, PaaS and IaaS
clouds. They have iden- tified, that for such feder- ation, well
defined poli- cies and protocols must be defined.
This architecture lacks management and autho- rized access
handling.It is not clear exactly how PaaS can act as a middle-
ware.
10
Table 1: Comparative Summary continued
Model, Author Aim Conceptual Approach Strength Weakness CONTRAIL
AR- CHITECTURE (Carlini et al., 2012) [37]
To minimize the burden on user and increase ef- ficiency of the
cloud platform, by performing horizontal (resolving interoperabil-
ity issues in cloud feder- ation) and vertical (pro- viding cloud
federation fa- cility at cloud stack level i.e. IaaS and PaaS
services) integration.
This architecture utilizes the resources of various cloud resource
providers, regardless of the hetero- geneity of underlying in-
frastructure. Complete open source approach is adopted here.
It handles interoperabil- ity issues by using open source
environment com- pletely. It also supports user authentication,
inte- gration of SLA manage- ment and application de-
ployment.
Though this model is quiet efficient, still there is s limitation
that how can we sure that each cloud resource provider is
trustworthy regarding his deliverables.
COMBINATORIAL AUCTION- BASED COL- LABORATIVE CLOUD (Zhang et al.,
2015) [38]
Their aim is to provide model for cloud collaboration considering
cost of com- munication and negotia- tion among clouds under
collaboration.
First, user layer receives requests from end-user. Second,
Auction-layer matches requests with cloud services provided by CSP.
Third, CSP- Layer forms coalition to improve serving ability to
satisfy demands of the user. For coalition forma- tion and to find
suitable partner for collaboration
This is a market-model for multiple cloud collab- oration, which
selects the suitable CSP according to demand of the user.
The results presented with this model are not tested with real-time
data so it is somewhat unac- ceptable model.
mOSAIC MULTI- CLOUD ARCHI- TECTURE (Petcu et al., 2013) [40]
This project provides solution for application portability and
interoper- ability across multiple clouds.
mOSAIC architecture is built from loosely cou- pled components that
en- hance the chances for the open-source software prototypes to be
adopted.
mOSAIC handles the problem of changing of cloud vendors. It has ap-
plication portability be- tween clouds via set of APIs. -Support
for dy- namic negotiations with multiple cloud providers using
brokering system.
This model lacks se- curity management. Event-driven program- ming
styleof mOSAIC application is complex.
EGI FEDER- ATED CLOUD [41]
EGI Feder- ated cloud integrates public, private or hybrid cloud in
the form of multi- national cloud system.
Each resource center op- erates cloud management framework (CMF)
ac- cording to its own prefer- ences and then joins Fed- eration
and Collaboration services.
User can access all ser- vices of cloud federation with a single
identity.
This federated cloud model lacks trust and unauthorized access
issues and other secu- rity features are not considered.
11
Table 1: Comparative Summary continued
Model, Author Aim Conceptual Approach Strength Weakness FEDERATED
CLOUD MAN- AGEMENT (FCM) AR- CHITECTURE (Marosi et al., 2011)
[35]
FCM in- corporates high level brokering for cloud feder- ation and
on demand auto- mated service deployments
several Infrastructure Providers exclusively dedicate their
computing infrastructure to a single cloud broker, which further
selects VM from underlying infrastructure provider for actual
execution of service
Conceptually, the model is simple and easy to un- derstand
Interoperable issues be- tween various cloud bro- kers in practical
scenario is not considered. Lack of management and secu- rity
constraints
CONTAINER TECHNOLOGY [42]
containers aims to pro- vide easy to deploy and secure
orchestration of specific self- con- tained virtual
infrastructure
Containers create an iso- lation boundary at appli- cation level
rather than at server level
Containers only requires software , libraries and basics of an
operating system and cloud contain- ers can be very easily de-
ployed on another server very easily.
Containers splits the vir- tualization into smaller chunks, that
creates dif- ficulty in management
SPINNAKER [43]
It provides two important features:1.Cluster man- agement
2.Deployment management.
Multiple heterogeneous cloud services can be availed through single
API.
Management and han- dling of multiple cloud clusters by connecting
through pipelines is a complex. It lacks secu- rity
management.
Cloud Foundry [44]
It aims to provide a standardized platform to the appli- cations of
customers by decoupling the applica- tion from its
infrastructure
CF offers two types of VMs: the component VMs as platform infras-
tructure and the host VMs that host applica- tions for outside
world.
The organizations can easily make a business decision on where to
de- ploy workloads i.e. on premise, in managed in-
frastructure
This model do not han- dles load balancing, secu- rity and data
storage han- dling issues.
SUPER CLOUD [45]
This work aims to pro- vide self- managed, self- protecting virtual
private clouds sepa- rately for each user.
All the CSPs are at bottom layer,supercloudlayer handles all the
inter- operability issues and provides complete ease of usage in
the hands of user.
Supercloud is self- managed, self- protecting cloud of
clouds,providing com- plete management of multi- clouds in the
hands of user.
Particularly in our view, this project model leaves no concern
untouched regarding multi-cloud set- up as such, also this project
work is in progress till now. But this project favours users more
than the cloud service providers.
UTILITY- ORIENTED FEDERATION OF CLOUD COMPUTING ENVIRON- MENTS
[46]
Inter-cloud framework which sup- ports scaling of applica- tions
across multiple ven- dor clouds.
Every client in federated environment needs to contact cloud
brokering service that can dynam- ically establish service
contracts with cloud co- ordinators through trad- ing functions
exposed by cloud Exchange
This model is efficient with respect to trust as cloud broker
selects CSP by negotiating with cloud coordinators.
Though trust is given pri- ority in this model, still there seems
no concern for security management.
12
Survey on Multi-Cloud Architectures A PREPRINT
[7] A. Singh and J. Kumar, “Secure and energy aware load balancing
framework for cloud data centre networks,” Electronics Letters,
vol. 55, no. 9, pp. 540–541, 2019.
[8] D. Saxena and S. Chauhan, “A review on dynamic fair priority
task scheduling algorithm in cloud computing,” International
Journal of Science, Environment and Technology, vol. 3, no. 3, pp.
997–1003, 2014.
[9] S. Saxena and D. Saxena, “Ewsa: An enriched workflow scheduling
algorithm in cloud computing,” in 2015 International Conference on
Computing, Communication and Security (ICCCS). IEEE, 2015, pp.
1–5.
[10] D. Saxena, R. Chauhan, and R. Kait, “Dynamic fair priority
optimization task scheduling algorithm in cloud computing: concepts
and implementations,” International Journal of Computer Network and
Information Security, vol. 8, no. 2, p. 41, 2016.
[11] D. Saxena and A. K. Singh, “Auto-adaptive learning-based
workload forecasting in dynamic cloud environment,” International
Journal of Computers and Applications, pp. 1–11, 2020.
[12] D. Saxena and A. Singh, “Security embedded dynamic resource
allocation model for cloud data centre,” Electronics Letters, vol.
56, no. 20, pp. 1062–1065, 2020.
[13] D. Saxena and A. K. Singh, “Energy aware resource
efficient-(EARE) server consolidation framework for cloud
datacenter,” in Advances in communication and computational
technology. Springer, 2021, pp. 1455–1464.
[14] J. Kumar, R. Goomer, and A. K. Singh, “Long short term memory
recurrent neural network (lstm-rnn) based workload forecasting
model for cloud datacenters,” Procedia Computer Science, vol. 125,
pp. 676–682, 2018.
[15] J. Kumar and A. K. Singh, “Workload prediction in cloud using
artificial neural network and adaptive differential evolution,”
Future Generation Computer Systems, vol. 81, pp. 41–52, 2018.
[16] J. Kumar, D. Saxena, A. K. Singh, and A. Mohan, “Biphase
adaptive learning-based neural network model for cloud datacenter
workload forecasting,” Soft Computing, pp. 1–18, 2020.
[17] J. Kumar, A. K. Singh, and A. Mohan, “Resource-efficient
load-balancing framework for cloud data center networks,” ETRI
Journal, vol. 43, no. 1, pp. 53–63, 2021.
[18] D. Saxena, A. K. Singh, and R. Buyya, “OP-MLB: An online vm
prediction based multi-objective load balancing framework for
resource management at cloud datacenter,” IEEE Transactions on
Cloud Computing, 2021.
[19] D. Saxena and A. K. Singh, “OSC-MC: Online secure
communication model for cloud environment,” IEEE Communications
Letters, 2021.
[20] D. Saxena and S. Saxena, “Highly advanced cloudlet scheduling
algorithm based on particle swarm optimization,” in 2015 Eighth
International Conference on Contemporary Computing (IC3). IEEE,
2015, pp. 111–116.
[21] S. Chhabra and A. K. Singh, “A secure vm allocation scheme to
preserve against co-resident threat,” International Journal of Web
Engineering and Technology, vol. 15, no. 1, pp. 96–115, 2020.
[22] I. Gupta and A. K. Singh, “A confidentiality preserving data
leaker detection model for secure sharing of cloud data using
integrated techniques,” in 2019 7th International Conference on
Smart Computing & Communications (ICSCC). IEEE, 2019, pp.
1–5.
[23] R. Gupta, D. Saxena, and A. K. Singh, “Data security and
privacy in cloud computing: Concepts and emerging trends,” arXiv
preprint arXiv:2108.09508, 2021.
[24] D. Varshney, B. Babukhanwala, J. Khan, D. Saxena, and A. kumar
Singh, “Machine learning techniques for plant disease detection,”
in 2021 5th International Conference on Trends in Electronics and
Informatics (ICOEI). IEEE, 2021, pp. 1574–1581.
[25] A. S. Chauhan, D. Rani, A. Kumar, R. Gupta, and A. K. Singh,
“A survey on privacy-preserving outsourced data on cloud with
multiple data providers,” in Proceedings of the International
Conference on Innovative Computing & Communications (ICICC),
2020.
[26] D. Saxena, R. Chauhan, and S. Saxena, “Global journal of
engineering science and researches.”
[27] K. Kaur, I. Gupta, A. K. Singh et al., “A comparative
evaluation of data leakage/loss prevention systems (dlps),” in
Proc. 4th Int. Conf. Computer Science & Information Technology
(CS & IT-CSCP), 2017, pp. 87–95.
[28] S. Chhabra and A. K. Singh, “A probabilistic model for finding
an optimal host framework and load distribution in cloud
environment,” Procedia Computer Science, vol. 125, pp. 683–690,
2018.
[29] R. Patel, V. Choudhary, D. Saxena, and A. K. Singh, “Review of
stock prediction using machine learning techniques,” in 2021 5th
International Conference on Trends in Electronics and Informatics
(ICOEI). IEEE, 2021, pp. 840–846.
13
Survey on Multi-Cloud Architectures A PREPRINT
[30] D. Saxena and A. K. Singh, “workload forecasting and resource
management models based on machine learning for cloud computing
environments,” arXiv preprint arXiv:2106.15112, 2021.
[31] J. Kumar, A. K. Singh, and R. Buyya, “Ensemble learning based
predictive framework for virtual machine resource request
prediction,” Neurocomputing, vol. 397, pp. 20–30, 2020.
[32] Q. Zhang, S. Li, Z. Li, Y. Xing, Z. Yang, and Y. Dai, “Charm:
A cost-efficient multi-cloud data hosting scheme with high
availability,” IEEE Transactions on Cloud computing, vol. 3, no. 3,
pp. 372–386, 2015.
[33] A. J. Ferrer, F. Hernández, J. Tordsson, E. Elmroth, A.
Ali-Eldin, C. Zsigri, R. Sirvent, J. Guitart, R. M. Badia, K.
Djemame et al., “Optimis: A holistic approach to cloud service
provisioning,” Future Generation Computer Systems, vol. 28, no. 1,
pp. 66–77, 2012.
[34] A. Galis, E. Elmroth, W. Emmerich, F. Galán, and S.
Telefónica, “The reservoir model and architecture for open
federated cloud computing,” IEEE Computer Society Press, vol. 20,
pp. 115–187, 2009.
[35] A. C. Marosi, G. Kecskemeti, A. Kertesz, and P. Kacsuk, “Fcm:
an architecture for integrating iaas cloud systems.” IARIA,
2011.
[36] I. Clouds, “A white paper from the open cloud standards
incubator,” Distributed Management Task Force, Version, vol. 1,
2009.
[37] E. Carlini, M. Coppola, P. Dazzi, L. Ricci, and G. Righetti,
“Cloud federations in contrail,” in European Conference on Parallel
Processing. Springer, 2011, pp. 159–168.
[38] X. Zhang, B. Li, and J. Zhu, “A combinatorial auction-based
collaborative cloud services platform,” Tsinghua Science and
Technology, vol. 20, no. 1, pp. 50–61, 2015.
[39] D. Villegas, N. Bobroff, I. Rodero, J. Delgado, Y. Liu, A.
Devarakonda, L. Fong, S. M. Sadjadi, and M. Parashar, “Cloud
federation in a layered service model,” Journal of Computer and
System Sciences, vol. 78, no. 5, pp. 1330–1344, 2012.
[40] D. Petcu, B. Di Martino, S. Venticinque, M. Rak, T. Máhr, G.
E. Lopez, F. Brito, R. Cossu, M. Stopar, S. Šperka et al.,
“Experiences in building a mosaic of clouds,” Journal of Cloud
Computing: Advances, Systems and Applications, vol. 2, no. 1, pp.
1–22, 2013.
[41] E. Fernández-del Castillo, D. Scardaci, and Á. L. García, “The
egi federated cloud e-infrastructure,” Procedia Computer Science,
vol. 68, pp. 196–205, 2015.
[42] V. V. Trofimov, V. I. Kiyaev, and S. M. Gazul, “Use of
virtualization and container technology for information
infrastructure generation,” in 2017 XX IEEE International
Conference on Soft Computing and Measurements (SCM). IEEE, 2017,
pp. 788–791.
[43] S. B. Furber, F. Galluppi, S. Temple, and L. A. Plana, “The
spinnaker project,” Proceedings of the IEEE, vol. 102, no. 5, pp.
652–665, 2014.
[44] D. Bernstein, “Cloud foundry aims to become the openstack of
paas,” IEEE Cloud Computing, vol. 1, no. 2, pp. 57–60, 2014.
[45] M. Lacoste, M. Miettinen, N. Neves, F. M. Ramos, M. Vukolic,
F. Charmet, R. Yaich, K. Oborzynski, G. Vernekar, and P. Sousa,
“User-centric security and dependability in the clouds-of-clouds,”
IEEE Cloud Computing, vol. 3, no. 5, pp. 64–75, 2016.
[46] R. Buyya, R. Ranjan, and R. N. Calheiros, “Intercloud:
Utility-oriented federation of cloud computing envi- ronments for
scaling of application services,” in International Conference on
Algorithms and Architectures for Parallel Processing. Springer,
2010, pp. 13–31.
14
2.1 CHARM
2.6 Distributed Management Task Force (DMTF) Architecture
2.7 Contrail Architecture
2.9 Layered Multi-Cloud Architecture
2.10 mOSAIC Multi-Cloud Architecture
2.11 EGI FEDERATED CLOUD
3 Conclusion and Future Directions
