=Paper=
{{Paper
|id=Vol-1871/paper7
|storemode=property
|title=MiCADO - Towards a Microservice-based Cloud Application-level Dynamic Orchestrator
|pdfUrl=https://ceur-ws.org/Vol-1871/paper7.pdf
|volume=Vol-1871
|authors=Hannu Visti,Tamas Kiss,Gabor Terstyanszky,Gregoire Gesmier,Stephen Winter
|dblpUrl=https://dblp.org/rec/conf/iwsg/VistiKTGW16
}}
==MiCADO - Towards a Microservice-based Cloud Application-level Dynamic Orchestrator==
https://ceur-ws.org/Vol-1871/paper7.pdf
8th International Workshop on Science Gateways (IWSG 2016), 8-10 June 2016
MiCADO – Towards a Microservice-based Cloud
Application-level Dynamic Orchestrator
Hannu Visti, Tamas Kiss, Gabor Terstyanszky, Gregoire Gesmier, Stephen Winter
Centre for Parallel Computing, University of Westminster, London, UK
(H.Visti, T.Kiss, G.Z.Terstyanszky,G.Gesmier, S.C.Winter)@westminster.ac.uk
Abstract—In order to satisfy end-user requirements, many duties. This can include heavy computation or storage based on
scientific and commercial applications require access to application use, which can vary significantly based on the nature
dynamically adjustable infrastructure resources. Cloud computing of the application.
has the potential to provide these dynamic capabilities. However,
utilising these capabilities from application code is not trivial and
requires application developers to understand low-level technical Application 1 Application 2 Application N
details of clouds. This paper investigates how a generic framework
can be developed that supports the dynamic orchestration of cloud
applications both at deployment and at run-time. The advantages
and challenges of designing such framework based on Service 1 Service 2 Service 3 Service 4 Service 5
microservices is analysed, and a generic framework, called
MiCADO – (Microservices-based Cloud Application-level Dynamic Resource requirements
Orchestrator) is proposed. A first prototype implementation of
MiCADO to support data intensive commercial web applications is
also presented. Variable resource consumption
Keywords—Cloud applications, application-level orchestration, Baseline resource consumption
microservices-based architectures, container technologies. Dynamic
Manually To be replaced by
demand automatically
I. INTRODUCTION adjusted
supply adjusted supply
Many scientific and commercial applications require access to Cloud services
computation, data or network resources based on dynamically
changing requirements. Applications running on distributed
Fig. 1: Resource demand and supply of cloud applications
computing infrastructures, such as grids or clouds, typically fall
into this category. End-users can access these applications via Overall resource demand is the sum of baseline and variable
desktop or web-based high-level user interfaces, such as science components, and the presence of a variable component makes
gateways. When executing applications or accessing services via the overall resource demand variable as well. IaaS
high-level user environments, users and providers both require (Infrastructure as a Service) clouds are elastic and have the
these applications or services to dynamically adjust to ability to supply a variable amount of resources. However,
fluctuations in demand and serve end-users at required quality of applications need to be specifically programmed in order to
service and speed, and also at optimized cost. The challenge of utilise this elasticity and dynamically vary the amount of
developing such dynamically adaptable applications without resources provided. Customising dynamic provision for each
requiring application developers to deal with low level details of application individually for a specific cloud environment is
the underlying distributed computing infrastructure is the topic costly to do. Our ultimate aim is to implement a generic service
of this paper. or layer that provides this functionality for any application
automatically, and in a cloud resource agnostic way.
One of well-documented benefits of cloud computing [1] is its
ability to supply a variable amount of resources (computational As shown in Figure 1, cloud service providers are indifferent to
power, storage, network capacity), which can scale dynamically the resource needs of applications since they have no means of
up and down, forming the supply side of figure 1. On the predicting application capacity demand behaviour. In practice,
demand side, we can see applications that are likely to be the operator of an application requests cloud resources based on
formed of one or more services. Services can be either in-house static predictive estimates (typically, worst-case estimates), but
developed or provided by external suppliers or open-source after being commissioned, these resources remain static without
communities. Services could also be shared between operator intervention. If demand exceeds supply at a given point
applications. of time, applications do not function within their required
parameters. If supply exceeds demand, resources are wasted,
Services consume baseline resources that can be defined as
which generally has a cost impact.
resources consumed by the component in idle state. Variable
resources are consumed when the component performs its
1
8th International Workshop on Science Gateways (IWSG 2016), 8-10 June 2016
This work investigates possibilities of replacing manually Applications developed by Stuttgart University. OpenTosca is
adjusted supply of cloud services with an automatically adjusted divided into three parts: a TOSCA runtime environment
supply, as also illustrated in Figure 1. The aim is to create a (OpenTosca container), a graphical modelling TOSCA tool
framework, where automatically adjusted cloud service supply (Winery) and a self-service portal for the application available in
can be arranged, based on application component demands. the container (Vinothek).
Such framework would allow cloud application developers to
Although effective in particular narrow circumstances, none of
build cost and performance optimization mechanisms into their
these systems provide a fully-automated, cloud-agnostic solution
application code through a high-level API.
for all, or even a wide range of applications and for wide variety
The suggested solution is based on microservices and their of clouds.
dynamic orchestration in a cloud computing environment. The
rest of this paper defines a generic microservices-based III. OPPORTUNITIES AND CHALLENGES OF MICROSERVICE-BASED
architecture for application-level cloud orchestration, called ARCHITECTURE DESIGN IN CLOUDS
MiCADO (Microservices-based Cloud Application level In order to support application-level orchestration and dynamic
Dynamic Orchestrator), and describes its first prototype resource provision in clouds, a microservices-based architecture
implementation utilizing container-based open source cloud is proposed. This section highlights the motivations behind this
technologies. approach and collects challenges that the architecture design
needs to overcome.
II. RELATED WORK
Software design based around microservices, in contrast to a
The problem of application-level orchestration has been
traditional monolithic architecture, is a relatively new concept,
recognized and a number of solutions have been designed and
and the literature does not yet have an agreed definition for
implemented. Marpaung et al. [2] discuss Altocumulus,
microservices. According to Newman “Microservices are small,
AppScale, Cloudify and mOSAIC. Altocumulus focuses on
autonomous services that work together”. His definition includes
deploying web applications to variety of public clouds, which
further characteristics, chiefly “focused on doing one thing well”
limits its usability in private or hybrid clouds. It does not
and being “autonomous” [8]. Balalaie et al write “Microservices
provide monitoring or dynamic changes to services. AppScale is
is [sic] a new architectural style [9] that aims to realize software
an open-source product that supports execution of Google
systems as a package of small services, each deployable on a
Application Engine applications and therefore restricted to this
different platform, and running in its own process while
particular technology. mOSAIC provides a set of APIs to
communicating through lightweight mechanisms like RESTFull
application developers to tackle cloud deployment issues. The
APIs.”
limitation of mOSAIC is the implementation of these APIs; the
application developer needs to integrate these to application Both Newman and Balalaie et al. see microservices mainly as an
components. agile development concept. A small, focused team can develop
one component of an application independently and deploy new
Cloudify [3] combines a TOSCA editor with deployment and
versions without changes to other components. In this paper, we
orchestrator. It provides access to multiple clouds and a
focus on deployment of microservices-based architecture, where
complete framework to describe microservices and execute them
connectivity between microservices becomes challenging.
either in Docker containers or on cloud metal. Cloudify also
provides dynamic service upscaling and downscaling based on Cloud computing is a natural platform for microservices.
microservice dependent parameters, for example number of Microservices achieve decoupling of independent components
transactions, number of threads, etc. Cloudify does not provide a from a monolithic application. Clouds enable execution and
container portability framework, nor do its metrics span resource allocation of these independent components based on
dockerised microservices and the cloud metal executing them. their specific needs. One microservice might require a lot of
storage while another could be CPU-intensive. Cloud execution
offers the possibility to optimise resource allocation, and thus
Pham, Tchana et al. discuss the problem of distributed
resource cost, dynamically. The alternative would be to allocate
applications [4]. They focus on application orchestration that can
a monolithic infrastructure, the size of which would be large
span several different clouds. They recognize the need to deliver
enough for a worst-case requirements scenario. However, for
microservice-specific parameters, for example port numbers and
most of the time, the worst-case scenario does not prevail and
IP addresses, to other microservices, and provide a description
allocated resources of the monolithic infrastructure are wasted.
language framework to do this. However, this solution does not
support service discovery tools and dynamic relocation of As discussed earlier, microservices provide APIs to enable
microservices. communication with them, and rely on APIs of other
microservices to access other services, on which they are
Amazon CloudFormation [5] provides to system administration depending. A typical API connection is a TCP (Transmission
developers an easier way for the collection, creation and Control Protocol) socket. To set up a TCP connection, the
management of related AWS resources through templates. These connecting computer needs two parameters: the IP address of the
templates describe the AWS resources and associated server host and a port number of the particular service on that
dependencies. After the deployment of AWS resources, host. Many port numbers are defined either officially in RFCs
CloudFormation ensures the start of services in the correct order. (Request For Comments), or by convention, and even in case of
a completely new service, the port number would remain static
OpenTosca [6] [7] provides an open source ecosystem for the within the particular architecture. The problem arises from
OASIS Topology and Orchestration Specification for Cloud dynamic IP address allocation strategy employed by the cloud.
2
8th International Workshop on Science Gateways (IWSG 2016), 8-10 June 2016
To form an API connection, the client application needs to know capacity were needed or any changes to the infrastructure were
the dynamically assigned IP address of the server host. initiated by changes in cloud services provisioning, an operator
would need to reconfigure microservices API information
In a microservices-based architecture commissioned on cloud,
manually. This could in many cases lead to suboptimal service
the IP address information may change during the life-cycle of
performance or waste, as from cost and workload management
the application. In a microservices-based model, microservices
viewpoint it might be easier to react to changed requirements
can and will be developed independently. Moreover, cloud
only when absolutely necessary. Automated monitoring and
computing provides dynamic allocation of hardware resources.
control could thus enhance benefits enabled by the use of cloud
From performance and financial optimisation, it would be
and microservices.
occasionally necessary to allocate more capacity by migrating a
microservice to a more powerful platform, or to consolidate less The above detailed challenges can be summarized as follows:
regularly used microservices to a single platform and shutting
C1. Discovery of IP addresses and port numbers of running
down some cloud capacity. By doing this, the IP address of the
microservices.
server host would change.
C2. Ability to run several microservices of the same kind on a
An additional challenge arises if multiple microservices single cloud instance.
providing the exact same service are deployed on the same host. C3. Allocation of microservices to cloud instances based on
If the service API is provided in an established port, only one of available resources.
the microservices could occupy this, and the others would need C4. Restriction mechanism to ensure microservices can only be
to be remapped. This would normally require changes to a allocated to cloud instances that have the functionality and
configuration file. For example, if a single cloud instance hosted capabilities of serving them.
three MySQL implementations, only one of them could use the C5. Ability to dynamically scale up and down. If cloud
default port 3306. Running the other two would require infrastructure usage exceeds given parameters, the condition
configuration file changes, including additional changes to must be detected and more cloud resources need to be
configuration files and service start-up scripts to assign a allocated.
different location to data and configuration files.
This work proposes an architecture that helps mitigate the
One workaround would be to ensure that only one microservice aforementioned challenges. The approach is also agnostic to
of a kind could run on each cloud instance. This would remove chosen applications, cloud providers, and microservices needed
the need to reconfigure port numbers and file locations, but it to provide applications.
might waste resources if new cloud instances would be needed
just for this purpose. Moreover, this would require building an IV. MICADO – THE PROPOSED SOLUTION
additional coordination layer to keep track of running cloud The proposed solution places microservices in lightweight
instances and currently running microservices, to be used to virtualisation containers in worker nodes. These containers can
allocate new microservices to cloud instances where such be hosted on any of the different worker nodes, and one node
microservices do not currently run. It would also be entirely can run one or more containers. An orchestration and
possible for two different services to occupy the same network coordination mechanism is required to enable service discovery
port. While not common, there is no mechanism or policy that and performance management. The overall MiCADO
would prevent this, especially if microservices came from (Microservices-based Cloud Application level Dynamic
different sources and their development were independent. Thus, Orchestrator) architecture is illustrated in Figure 2. The solution
the aforementioned mapping would need to consider network takes the following overall approaches to challenges identified
services as well as file system locations to ensure there is no in section III:
overlap between two microservices designed to share the same
cloud instance. In Section V we will show such steps are C1. To address dynamic discovery of IP addresses and ports,
unnecessary. use a service discovery framework. Several such
frameworks exist, for example Consul [10], Zookeeper [11]
Obtaining benefits from the dynamic nature of cloud requires an and Etcd [12].
understanding of current and/or predicted resource usage, and C2. To enable deployment of several microservices of the same
the possibility to scale infrastructure up or down on demand. A kind on the same instance, use kernel namespace based
mechanism is needed to analyse usage, allocate microservices to lightweight virtualisation solution to run microservices in
cloud instances best suited to serve them, and allow optimisation containers. These solutions (for example Docker [13] built
based on given parameters, such as performance or cost. on Linux containers) provide separation of application files
Microservices can set different requirements to physical cloud and allow port mapping functionality to masquerade
instances and resources based on the nature of the service. For standard microservice API ports to dynamically allocated
example, an authentication service would require little CPU ones.
power or storage, an HTTP application server would require C3. To support the allocation of microservices to cloud
considerable CPU power but little storage, and a database server instances based on available resources, form a cluster of
could require both powerful computation and storage worker nodes that is aware of the capacity and status of each
capabilities. node, and is able to make service allocation decisions based
Setting up a static microservices based architecture on cloud on a documented logic.
would be possible manually, by designing the correct launch C4. The chosen clustering mechanism must be aware of the
order of services, and configuring manually IP addresses of the hardware configuration of cloud instances, and allow
already started services to those depending on them. If more constraints to be set to limit automatic allocation decisions
3
8th International Workshop on Science Gateways (IWSG 2016), 8-10 June 2016
(C3) to those nodes that have the requisite physical Information needs to be gathered and processed. If
capabilities, for example a public IP address, to serve a bottlenecks are detected or the currently running
particular microservice. infrastructure appears underutilised, it may be
C5. To support automatic scaling up and down, the cluster needs necessary to either launch or shut down cloud
to have an alert mechanism, to help cluster management instances, and possibly move microservices from one
detect nodes and services that exceed thresholds or nodes physical worker node to another.
that appear to be underutilised. Decision-making logic c) Microservices discovery and execution layer. This layer
needs to be programmed based on this information or manages the execution of microservices and keeps
obtained within a software component. The logic needs to track of services running. Execution management
have interfaces to clouds to start and shut down instances, combines both start-up and shut-down of
and to container start-up and shutdown mechanisms. microservices. Service management gathers
MiCADO information about currently running services.
Application
layer App1 App2 App3 Information gathered includes service name, IP address
and port where the service is reachable, and optional
Application
infrastructure Infrastructure definition 1 Infrastructure definition 2 service tags to help in service coordination.
definition layer
d) Coordination interface API. This layer provides access
Coordination interface API to orchestration control and decouples the orchestration
Microservices discovery and execution layer layer from the application infrastructure definition. This
Orchestration
layer Microservices coordination logic layer set of APIs enables application developers to utilise the
Cloud interface API dynamic orchestration capabilities of the underlying
Cloud interface
layer and support the convenient development of
layer Cloud access API dynamically and automatically scalable cloud-based
applications.
Cloud instance
Worker node 1 Worker node 2 Worker node N
layer Contai Contai Contai Contai Contai Contai Contai Contai Contai
4) Application infrastructure definition layer. This forms
ner ner ner ner ner ner ner ner ner
the basis for creating a functional application infrastructure.
At this level, software components and their requirements
Fig 2: Generic MiCADO architecture
as well as their interconnectivity are defined. This layer
Based on the above described generic approaches to handle the does not contain any application-specific data. For example,
five identified challenges, the following layered architecture is to provide HTTP based services, this layer can define that to
proposed for the application level orchestration of cloud provide this functionality, a MySQL database, Apache
applications. The layers in the box entitled MiCADO represent HTTP server and Nginx proxy server are needed, and that
the actual orchestration architecture. Layers below MiCADO Nginx needs connection to Apache, which in turn needs
provide access to cloud resources, while the top layer represents connection to MySQL. As the infrastructure is agnostic to
actual applications to be optimized. The layers in Figure 2 are the actual application using it, this definition can be shared
described from bottom to top. with any application that requires such an environment.
5) Application layer. This layer contains actual application
1) Cloud infrastructure layer. This layer contains cloud
code and data to make an incarnation of a defined
instances, which in turn run containers that execute actual
application infrastructure (4) function in such a way that the
microservices. One instance can run one or more containers.
desired functionality is achieved. For example, this layer
2) Cloud interface layer. This is a set of APIs that provides
could populate a database with initial data, and configure an
means to launch and shut down cloud instances. There can
HTTP server with both look and feel and application logic.
be one or more cloud interfaces to support multiple clouds.
Either native interfaces of targeted clouds can be applied V. MICADO REFERENCE IMPLEMENTATION
(e.g. EC2) or generic cloud access layers that provide access
A prototype of the proposed MiCADO architecture has been
to multiple heterogeneous clouds.
implemented via a combination of open-source tools and in-
3) Microservices orchestration layer. This is divided into
house developed extensions, as is illustrated in Figure 3.
four sub-layers.
Although it would be possible to develop a platform to
a) Cloud interface API. This layer is needed to abstract
implement MiCADO functionality from scratch, reusing and
cloud access from the layers above. Cloud access APIs
utilizing existing open-source components has significantly
can be complex interfaces, as they typically cater for a
speeded up the implementation process. As a restriction, this
large number of services provided by the cloud
first MiCADO prototype does not include Cloud interface and
provider. On the other hand, the microservices
Coordination interface APIs. The Coordination interface API is
execution and coordination logic layers (see 3b and 3c)
replaced by a simple command line, and the Cloud interface API
only need to shut down and start instances. Abstracting
is represented by direct calls towards the cloud access layer (in
this to a cloud interface API simplifies the
this case the CloudBroker Platform [14] [15]). Moreover,
implementation of the aforementioned layers, and
instead of a generic approach towards infrastructure definition, a
equally, if new Cloud access APIs are implemented,
concrete architecture has been realized implementing a real-life
only this layer needs to change.
case-study. Applying these limitations, a proof-of-concept
b) Microservices coordination logic layer. With large
implementation has been completed to justify the validity of the
infrastructures, and to reap the benefits from cloud-
proposed approach when handling the five challenges detailed in
based execution, it becomes necessary to understand
section III. For infrastructure management and orchestration the
how the current execution environment is performing.
4
8th International Workshop on Science Gateways (IWSG 2016), 8-10 June 2016
following tools have been selected to implement the previously [21]. An installation of the platform that is operated by the
described MiCADO layers. CloudSME European Project [22] was utilized in our
experiments. Using the CloudBroker Platform, even this very
Microservices discovery layer was implemented based on
first MiCADO implementation is capable of interfacing with a
Consul [10]. Consul is an open-source service discovery tool
large variety of clouds without further cloud interface plug-in
that also includes health check and alerts functionality. An
development.
additional component, Registrator [16] is used on worker nodes
to register information on running containers to Consul. For cloud instances, an Ubuntu 14.04 image was prepared with
Docker, Consul, Swarm and Registrator installed. The
Consul agents can work either in a server or serf role [17].
CloudBroker platform provides a mechanism for preparing such
Servers keep track of events happening in the network and
images to be later launched in participating clouds. In addition to
notify other servers of changes, while serfs create a server
pre-installed applications, the cloud image needs a start-up script
connection and maintain a list of backup servers. Consul servers
to initialise and launch the above mentioned tools. Consul and
create network overhead by communicating between themselves
Docker create, upon initial start, random identifiers to
using Consensus protocol [18]. In large environments, most
distinguish between nodes in the same cluster. When a cloud
nodes should be configured as serfs to minimise this traffic. In
instance launches the first time, it needs to remove these
the proof of concept example, the master and all nodes are
identifiers to force initialisation.
configured as servers, to keep node configurations identical.
Application MiCADO
When a Consul agent starts, it needs to connect to an existing layer Customer 1 app Customer 2 app Customer 3 app
network. This can be provided either by a specific Consul server
Application
set in bootstrap mode, by connection to a node or set of nodes infrastructure Nginx, Node.js stack, MongoDB Another application infrastructure
definition layer
already running Consul, or by connection to Atlas service [19].
Coordination interface API (Built in-house)
Atlas is a service that registers running Consul infrastructures
Consul
Microservices discovery and execution layer (built in-house)
based on a secret token. When a Consul agent configured to use
Monitoring
Orchestration
Atlas starts, it registers itself with the service and queries for layer Microservices coordination logic layer (Docker + Swarm)
other nodes already present. The service is provided via a REST Cloud interface API (Built in-house)
API, making it easy to use from firewalled networks. The first Cloud interface
layer Cloudbroker Platform
node registering does not receive anything. When the second
node joins the infrastructure, it registers itself and receives in Cloud instance
Worker node 1 Worker node 2 Worker node N
response the details of the first node, allowing it to initialise layer Contai
ner
Contai
ner
Contai
ner
Contai
ner
Contai
ner
Contai
ner
Contai
ner
Contai
ner
Contai
ner
connection to it. When a server finds one Consul server, it
communicates with it and shares information about the entire Fig. 3: MiCADO reference implementation
network. Thus, a Consul network does not need to be described
in nodes, only the bootstrap information needs to be present. Application infrastructure definition layer currently
implements one particular topology based on a specific set of
Registrator is started on all worker nodes. Registrator is a helper use-cases provided by Outlandish LLP [24]. Outlandish is a
process to Consul that registers all running Docker containers to small employee-owned digital agency specialising in
it. Registrator runs in a Docker container itself, and it can be middleware, usability, search and scalable data applications.
started either locally or via the Swarm launch mechanism. The Outlandish develops and hosts various web applications for
roles of Docker and Swarm will be explained in detail under the multiple corporate clients. Usage estimates vary greatly between
Microservices coordination logic layer. applications and customers, and in some cases, usage activity
Microservices coordination logic layer was implemented can be expected to vary greatly based on external triggers, such
based on Docker and Swarm [20]. Swarm is a clustering as calendar, time of day, outside events and news. The company
mechanism built on Docker that is aware of worker nodes and wishes to serve its clients to agreed quality of service but also
their current workload, and is able to allocate new containers to tries to minimise its costs on the provision side. Therefore, a
the node currently least used. Docker and Swarm allow the cloud-based application deployment and hosting environment
capability of giving worker nodes “tags” to enable the use of that is capable of making such optimisation choices dynamically
constraints. For example, giving a different tag to nodes with a at run-time is highly desired.
lot of disk space allows allocation of database containers to A typical Outlandish application is formed of three components:
these particular nodes, while worker nodes tagged for proxy use proxy servers with public IP address, application servers and
will have a public IP address. To fulfil requirement C4, worker database servers, as illustrated in Figure 4. The concrete
nodes are tagged with their roles. The tags used in the current implementation applies Nginx reverse proxy servers, Node.js
application scenario are proxy, application and database (see stacks for application servers, and MongoDB databases. This
Application infrastructure definition layer later on). This tag is set-up is generic for several Outlandish-developed and -hosted
set in the Docker start-up configuration file. applications and as a consequence, several application scenarios
Cloud Access API layer is represented by calls to the and clients can be served based on this application pattern.
Cloudbroker Platform. The Cloudbroker Platform is a The currently implemented MiCADO prototype successfully
production level tool developed by a CloudBroker GmbH that deploys the above described generic architecture for several
allows interfacing to various commercial IaaS clouds, for Outlandish applications into Docker containers, clusters these
example Amazon and CloudSigma, and also to private cloud containers based on Swarm, and provides the required service
infrastructures based on Openstack, OpenNebula and Eucalyptus discovery mechanism via Consul and Registrator. Outlandish
5
8th International Workshop on Science Gateways (IWSG 2016), 8-10 June 2016
application developers need only provide the application code this instance to manage their applications formed of multiple
and the corresponding Docker configuration files. The optimised microservices.
deployment to available cloud instances is managed by
Application developers first need to create a Docker image of
MiCADO. Therefore, the implemented solution successfully
the specific microservice they want to deploy (for this process
addresses challenges C1-C3 (IP address and port number
no specific support is provided currently in MiCADO). This
discovery, running same kinds of microservices on a cloud
Docker image is then uploaded to a private Docker registry
instance, and allocating microservices to cloud instances based
operated by the CloudSME project. In order to launch a new
on available resources), and also by tagging the resources it
Docker container with a required image, application developers
provides mechanisms to support C4 (allocate microservices to
need to execute a Python script from [25] providing the name of
specific instances that have the capabilities to serve these).
the image and the type of node (e.g. node with public IP address
However, please note that this current prototype does not offer
for a Proxy server) as parameters. The container will be
run-time monitoring and automated optimisation capabilities
launched to the least utilised node automatically by Swarm.
(C5) that is part of our future work.
When a new container is launched, MiCADO checks whether
Internet there is enough memory available on current cloud instances to
Public IP
run the container. If there is not enough memory available, then
a new instance is launched automatically, and the launch of the
HTTP proxy1 HTTP proxy 2 HTTP proxy N container will be held until the new cloud instance is up and
running on the infrastructure.
Private IP
The current MiCADO prototype also supports automated
App server 1 App server 2 App server 3 App server N
downscaling of the infrastructure at run-time. There is a cron job
running continuously to determine if the infrastructure needs to
be downscaled. This cron job will first establish which instance
on the infrastructure is the least utilized. It will then list all the
DB server 1 Replication DB server 2
running containers on the least utilized instance and get their
memory usage. The cron job will check if the memory usage on
Fig. 4: Web-based application infrastructure example the instance is less than the availability on the rest of the
implemented for the Outlandish use-cases infrastructure. If there is enough memory available on the other
running instances then it will check if each container can be
VI. DEPLOYING AND MANAGING APPLICATIONS WITH MICADO relocated on another instance. If the containers can be relocated
Based on the above described first proof-of-concept reference then these are launched on the other instances, the containers on
implementation of the MiCADO framework, a short overview the least utilized instance are stopped and removed, and finally
on how this implementation supports the deployment and the least utilized instance is stopped and removed from the
management of cloud applications is provided in this section. infrastructure. With this functionality MiCADO provides some
Please note that the current implementation supports only basic capabilities to optimize resource utilization and therefore
command-line access. However, the objective of our future save unnecessary expenses for application providers.
research is to develop a set of well-defined APIs that can be
conveniently embedded into desktop or web-based science VII. CONCLUSIONS AND FUTURE WORK
gateway solutions. This paper collected and analysed challenges towards a
Before an application developer can utilize MiCADO services, microservices-based implementation of a dynamic application
certain infrastructure components need to be deployed and set- level cloud orchestrator called MiCADO. Moreover, it presented
up by an administrator. A specific set of scripts has been a first proof-of-concept implementation of the architecture that
developed [25] that can be used to create and deploy the successfully addresses four out of the five identified challenges,
necessary virtual machine images on the CloudBroker Platform. and also facilitates a future implementation to tackle the fifth
MiCADO differentiates between two types of virtual machines: challenge. The MiCADO concept succeeds in decoupling
manager and worker nodes. The manager node runs permanently application level logic from cloud orchestration logic, while
until the infrastructure is required and can be used to deploy or preserving the elastic and dynamic nature of the cloud. The
terminate microservices running in containers, or cloud experiment shows it is possible to narrow the gap between IaaS
instances. Worker nodes are hosting various Docker containers and SaaS models.
running different microservices (e.g. applications, databases or While the solution was tested on the infrastructure described
proxies, as illustrated in figure 4). Both manager and worker earlier, there is no fundamental reason why the principles could
node images include Docker, Consul and Swarm. not be applied to other operating systems, monitoring tools,
In order to create a new MiCADO installation, the administrator service discovery tools and cloud APIs. The most significant
needs to launch a manager node instance through the limitations are in security, performance measurement and
CloudBroker platform in the target cloud. Please note that as the downscaling. No work has been done on infrastructure level
CB platform is used at the cloud access layer, the solution is security. Network overhead incurred by Consul and Swarm has
cloud-agnostic, and the manager node can be launched in any not been investigated, nor has the CPU overhead caused by
targeted could in which an image has been created. Once the Docker. Consul has a built-in mechanism to reduce network
manager node is launched, application developers can log-in to overhead by designating only a few nodes as servers and the rest
as serfs. Therefore, more work would be needed to define the
optimal configuration. Moreover, performance measurement has
6
8th International Workshop on Science Gateways (IWSG 2016), 8-10 June 2016
been done on a most basic level, to prove a concept instead of [6] Anon. (2015). OpenTosca [online] Available from: [Accessed 16/03/2016]
providing a ready solution. [7] Binz, Breiter, Leyman, & Spatzier. (2012). Portable Cloud Services Using
As this paper only analysed the MiCADO concept and presented TOSCA. Internet Computing, IEEE, 16(3), 80-85.
[8] Newman, Sam. (2015). Building Microservices. O'Reilly.
a proof of concept implementation, future work is rather [9] Balalaie, A., Heydarnoori, A., & Jamshidi, P. (2015). Migrating to Cloud-
versatile. On the one hand it should evolve around measurement Native Architectures Using Microservices: An Experience Report.
and optimization logic of dynamic scalability. As this is the core [10] HashiCorp. (2016). CONSUL by HashiCorp [online] Available from:
[Accessed 16/03/2016]
of the MiCADO platform, making this more versatile and [11] Apache. (2016). Apache Zookeeper [online] Available from:
intelligent without sacrificing usability is a challenge. Another [Accessed 16/03/2016]
aspect includes infrastructure definition reusability and sharing. [12] Coreos. (2016). Etcd [online] Available from:
This could lead to a definition of application topology and [Accessed 16/03/2016]
[13] Anon. (2016). Docker [online] Available from
description templates that are applicable for a wide range of [Accessed 16/03/2016]
application scenarios. For such purposes we are looking at [14] Anon. (2016). CloudBroker Platform [online] Available from:
existing standardized description formats, such as TOSCA [Accessed 15/03/2016]
[15] Taylor SJE, Kiss T, Terstyanszky G, Kacsuk P, Fantini N. (2014). Cloud
(Topology and Orchestration Specification for Cloud Computing for Simulation in Manufacturing and Engineering: Introducing
Applications) by OASIS [23]. Another angle for future work is the CloudSME Simulation Platform. Proceedings of the 2014 Annual
information security related to service up/downscaling and Simulation Symposium, ANSS ’14, Society for Computer Simulation
portability, as this has not been touched at all. International: San Diego, CA, USA, 2014; 12:1–12:8.
[16] Anon. (2016). Registrator [online] Available from:
[Accessed 16/03/2016]
VIII. ACKNOWLEDGEMENTS [17] Anon. (2016). Consul Architecture [online] Available from:
This work was funded by the CloudSME Cloud-Based [Accessed
16/03/2016]
Simulation platform for Manufacturing and Engineering Project [18] Anon. (2016). Consensus Protocol [online] Available from:
No. 608886 (FP7-2013-NMP-ICT-FOF). We also acknowledge [Accessed
the contribution of Outlandish LLP whose staff provided us with 16/03/2016]
[19] Anon. (2016). Atlas Integration [online] Available from:
vital information regarding their requirements and valuable [Accessed 16/03/2016]
feedback throughout the implementation. [20] Anon. (2016). Docker Swarm Overview [online] Available from:
[Accessed 16/03/2016]
REFERENCES [21] Baset, Salman, A., Carey, Michael, & Hand, Steven. (2012). Open source
cloud technologies. Cloud Computing Proceedings of the Third ACM
[1] Thomas, D. (2009). Cloud Computing — Benefits and Challenges! Symposium, 1-2.
The Journal of Object Technology, 8(3), 37. [22] Kiss, T, Dagdeviren, H, Taylor, JES, Anagnostou, A, Fantini, N. (2015).
[2] Marpaung, Sain, & Hoon-Jae Lee. (2013). Survey on middleware systems Business Models for Cloud Computing: Experiences from Developing
in cloud computing integration. Advanced Communication Technology Modeling & Simulation as a Service Applications in Industry, Proceedings
(ICACT), 2013 15th International Conference on Advanced of the 2015 Winter Simulation Conference, Pages 2656-2667, ISBN: 978-1-
Communications Technology, 709-712. 4673-9741-4, IEEE Press
[3] Anon, (2016). Cloudify [online] Available from: [23] Oasis committee specification (2013). Topology and Specification for
[Accessed 16/03/2016] Cloud Applications version 1.0 [online] Available from: [Accessed
Palma, N. (2015). An adaptable framework to deploy complex applications 15/03/2016]
onto multi-cloud platforms. The Institute of Electrical and Electronics [24] Anon. (2016). Outlandish [online] Available from < http://outlandish.com/
Engineers, Inc. (IEEE) Conference Proceedings, 169-174. > [Accessed 19/03/2016]
[5] Anon. (2016). AWS CloudFormation [online] Available from: [25] Anon. (2016). MiCADO setup scripts [online] Available from <
[Accessed 16/03/2016] https://github.com/gregGes/DSCR-infrastructure> [Accessed 08/05/2016]
7