1939-1374 (c) 2015 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation
information: DOI 10.1109/TSC.2015.2428257, IEEE Transactions on Services Computing
AUTHOR ET AL.: TITLE 3
Figure 1. Taxonomy of unified cloud management actions, events and metrics.
3.1 Taxonomy
The taxonomy was proposed through a systematisation of
cloud providers with insights taken from existing cloud
management tools and approaches.
Fig. 1 shows the taxonomy of unified cloud manage-
ment actions, events and metrics, which shows how ac-
tions related to a subject (e.g. servers, images, etc.) and
how actions are created to manage events and metrics.
Once the required actions, events and metrics were iden-
tified, the implementation details were incorporated such
as parameters and return values. Due to space limit, we
do not discuss details here.
3.1.1 Actions
The actions are essential for the unified management of
cloud systems. Most of the actions produce an almost
ono-to-one mapping with functionality provided by
cloud providers. For example, a server can be created,
resized, deleted, started and stopped in almost all cloud
providers. However, there are more complicated methods
such as ForkServer, and the processes management set.
The ForkServer action is an adaption of the fork pro-
cess command found in UNIX, which currently does not
exist in practice, but was found in the [26]. ForkServer
creates a new server by cloning another server and hence
giving the new server a copy of its state. Compared to
deploying a normal server, the benefit of ForkServer is
that when it comes time to scale, it will take less time to
deploy as the new worker server will already have run-
time state. Though ForkServer is not currently provided
by cloud providers, it could be implemented in the future
due to its advantage of cloning run-time state.
The process management currently does not exist in
the functionality provided by IaaS cloud providers, but
rather is found in PaaS and SaaS. However, running ap-
plications on an IaaS deployment is necessary as there is
no point having a server and not executing applications
on it. As a result of this requirement, workarounds were
created that relied on SSHing commands to execute, re-
start and terminate processes on IaaS based clouds.
3.1.2 Events
Events occurring in cloud vary significantly from provid-
ers to provider and from type to type. Therefore, it is im-
possible to create a list of events that is generic enough to
support the majority cloud providers. It was also found
that when a cloud provider offered event callbacks,
webhooks were the selected as the form of communica-
tion. This means when an event occurs, the given URL
specified in the webhook is sent information about the
event. Therefore, to overcome the limitation of varying
events and utilise the webhook interface provided by the
cloud providers, the event management set was created.
This event management set is actually a set of actions,
which are used to list and subscribe to events. The ListE-
vents action is the solution that allows for the dynamic
discovery of events supported by cloud. To receive a noti-
fication of a supported event, the RegisterCallback-
Webhook is used to setup a subscription to the given
event. This means when the event occurs, the registered
callbacks address is sent information about the event.