ChapterPDF Available

Abstract and Figures

The new-coming 5G network is considered to be one of the most significant innovations today. This is due to the opportunities that is going to provide to the vertical industries. 5G infrastructures will introduce a new way for low-delay, reliable deployment of services. In fact, such infrastructures can be used for the placement of application services in the form of application graphs. An application graph consists of several application components (i.e. micro-services) that may be hosted in the same infrastructure or in different ones. Conflicting requirements that arise when deploying in such infrastructures are now handled through network slicing, which regards a way for partitioning conventional network and computing resources into virtual elements. In this paper, we define a universal application metamodel of a 5G compatible application in order to guarantee the annotation of each application descriptor with its proper requirements for their fulfillment at the instantiation time. In terms of application architecture, we consider each application graph as a service mesh topology in order to adopt this novel service architecture as a dominant methodology that is well fitting in the promising 5G capabilities.
Content may be subject to copyright.
Modelling 5G cloud-native applications by exploiting
the service mesh paradigm
Ilias Tsoumas1, *, Chrysostomos Symvouilidis1, Dimosthenis Kyriazis1,
Panagiotis Gouvas2, Anastasios Zafeiropoulos2, Javier Melian3, and Janez
1 Dept. of Digital Systems, University of Piraeus, Piraeus, Greece
{itsoum, simvoul, dimos}
2 Ubitech Ltd., R&D Dept. Athens, Greece
{pgouvas, azafeiropoulos}
3 ATOS, Tenerife, Spain
4 Internet Institute, Ljubljana, Slovenia
Abstract. The new-coming 5G network is considered to be one of the most
significant innovations today. This is due to the opportunities that is going to
provide to the vertical industries. 5G infrastructures will introduce a new way
for low-delay, reliable deployment of services. In fact, such infrastructures can
be used for the placement of application services in the form of application
graphs. An application graph consists of several application components (i.e.
micro-services) that may be hosted in the same infrastructure or in different
ones. Conflicting requirements that arise when deploying in such infrastructures
are now handled through network slicing, which regards a way for partitioning
conventional network and computing resources into virtual elements. In this
paper, we define a universal application metamodel of a 5G compatible
application in order to guarantee the annotation of each application descriptor
with its proper requirements for their fulfillment at the instantiation time. In
terms of application architecture, we consider each application graph as a
service mesh topology in order to adopt this novel service architecture as a
dominant methodology that is well fitting in the promising 5G capabilities.
Keywords: 5G-ready applications • application components metamodels •
application graphs • service mesh • cloud-native applications
1 Introduction
5G comes in a revolutionary way to change forever both the internet, and the World
Wide Web (WWW), whereas their combination will certainly change the existing
vertical industry. This will be realized through the provision of an ultra-fast wireless
WWW that will lead to the 4th Industrial Revolution. More specifically, the main
purpose of 5G is to combine multiple technologies of different layers and areas in
order to achieve its goals, aiming mainly at higher capacity, higher data rate, lower
end-to-end latency, massive device connectivity, reduced cost, as well as consistent
quality of experience provisioning [1]. Network softwarization will play a key role to
this, hence methodologies such as Network Slicing (NS) and Cloud Computing
methodologies will be used in consolidation.
One of the existing major challenges of 5G is the integration of vertical industries. In
more detail, the challenge regards the adoption of 5G capabilities from the
applications and the procedures of the vertical industries. Nevertheless, it is necessary
to define a proper model of them so as to be harmonized with 5G architectures.
There are innumerable non-monolithic applications that run in a distributed manner.
For the proper deployment of these distributed applications in the virtual
environments of 5G networks, it is crucial to capture their computing and networking
requirements, as well as to monitor their components at runtime and adapt to any
environment changes may appear [17] in order to make possible their consistent
instantiation inside of 5G. Thus, the applications will be ready to be deployed in 5G
environments, following and extending the cloud-native rules of the containerization,
the dynamic orchestration, and the micro-services orientation [12].
In order to address these challenges, this paper focuses on the provision of a rich
description of 5G-ready applications, as a metamodel. A 5G-ready application
consists of several chainable components (i.e. micro-services). The interaction
between these components can be depicted by a directed acyclic graph, which is
referred as a 5G-ready application graph. The proposed approach exploits the service
mesh paradigm, since it achieves (i) security with Transport Layer Security (TLS) and
key management, (ii) observability via metrics, monitoring, and distributing tracing,
(iii) clear separation between business logic and the network layer 7 (L7)
functionalities, (iv) primitive routing capabilities, as well as (v) resiliency for inter-
service communications (i.e. circuit-breaking, retries and timeouts, fault handling,
load balancing, etc.), through the data plane (via sidecar proxies). Through a control
plane, policy and configuration for all the running data planes in the mesh
transformed into a distributed system are provided [10].
The overall description addresses two fundamental entities; the chainable component,
and the 5G-ready application graph. The key outcome is the metamodel of these two
entities, which are then used for the request of a computing and network slice in order
to deploy the 5G-ready application, both by the network and the cloud computing
Eventually, the application graph metamodel is going to be used by the slice intent
metamodel. The latter refers to a description of the request of the Application provider
(Vertical / northbound orchestrator) to the Network Service provider (Telco /
southbound orchestrator), regarding the network and the compute slice that are
needed. In order to provide the requested resources, the Network Service provider
needs information regarding the requirements of each application component and the
topology of the given application graph. That information is depicted in the
application graph metamodel, since it contains information regarding the links
between the application components of the application graph.
The chainable application component metamodel describes and verifies (with the aid
of some supporting mechanisms introduced in Section IV) the following: (i) the
required information for the proper deployment and execution of the components (e.g.
resource requirements), and (ii) the alignment with a set of rules in terms of QoS
requirements, cloud-nativeness affected by the 12-factor manifest [2]. The application
graph (service mesh) metamodel is the collection of the bindings among the exposed
and required interfaces per chainable component. Both at component and at graph
level, the denotation of a set of computing, memory, storage and network
requirements are being supported in correlation with the corresponding slice intent
metamodel [3].
The rest of the paper is organized as follows: Chapter II presents the State of the Art
in the area of modelling applications and services. Chapter III presents the approach
of the authors, including a detailed demonstration of the developed metamodels.
Chapter IV regards the experimental evaluation of the proposed architecture in a real-
life deployment scenario. Finally, Chapter V concludes the paper and suggests future
work based on the current model.
2 Related Work
There exist various researches in the literature concerning the modelling schemas that
have been developed and used for application components and services, as well as
application graphs and network services so far. Juju [13] is an open-source modelling
framework [14] developed by Canonical that is used for managing, deploying and
scaling services in the cloud in the form of application graphs. A Juju charm, (i.e. an
application component) contains information that is necessary for a service to be
orchestratable and composable. Several charms wired together with virtual links
create a Bundle that is in fact the application graph. The descriptors of both charms
and bundles are created in YAML containing crucial information for the orchestration
of a service.
Another interesting approach regards the descriptors used in ARCADIA framework
[15], an EU-funded research project that is created for the design and development, as
well as the dynamic setup and management of highly distributed applications over a
programmable infrastructure. The ARCADIA framework uses a context model to
describe these applications. This context model [16] is used for the proper
representation of distributed applications designated as service graphs, including four
main models, the component model, the service graph model, the service deployment
model, and the service runtime model. The component model is used as the descriptor
of the nodes that wired together form a service graph, preserves information for the
components, for other components to connect with them properly, and the
requirements that have to be fulfilled for the component to run smoothly, etc.
On the other side, the service graph model contains information regarding the whole
service graph, like the “Virtual Link Descriptor” that holds the information related to
the links between two components. Regarding the service deployment model, this is
responsible for the placement of the service graph into the Infrastructure as a Service
(IaaS) resources, where the service runtime model is a representation of an instance of
a deployed service graph by the orchestrator.
The Open-source MANO (OSM) [19] is an ETSI-hosted project offering an Open
Source NFV Management and Orchestration (MANO) software stack, aligned with
ETSI NFV. For that purpose, a strong data model is created, and is used to describe
the ETSI MANO objects, modeled as YANG objects. It consists of several descriptors
such as the Network Service descriptor that is responsible for containing information
related to the deployment of a Network Service, the virtual network functions (VNF)
descriptor that holds information regarding the attributes of a VNF, and the resource
requirements, etc. [19].
Finally, Bruneliere et al. [20] present a generic model-based architecture created in
YAML language to allow the automation of the management of any cloud system.
The proposed architecture consists of two main metamodels, where the first is used
for the description of the structure of any given topology, and the second one for the
representation of the relationship between nodes and any constraints that may exist.
3 Proposed approach
This chapter describes our approach regarding the way a 5G-enabled application
should be modeled in order to exploit the advantages of the new-coming 5G era. At
first, we present a way to properly introduce cloud services in the 5G world using the
service mesh approach. Then, we showcase our approach regarding the way the
application components and the application graphs should be described in our
metamodel in order to exploit the advantages of 5G enabled cloud infrastructures.
3.1 The Service Mesh approach
One of the biggest challenges in the 5G evolution lies in the way we properly
introduce services and the Service Oriented Architectures (SOAs) in the 5G
environments [4].
An approach to address this challenge is by using Mesh Applications and Service
Architecture (MASA). The high-level difference of MASA from SOA is summed up
on this “The mesh app and service architecture (MASA) is a multichannel solution
architecture that leverages cloud and serverless computing, containers and
microservices as well as APIs and events to deliver modular, flexible and dynamic
solutions. Solutions ultimately support multiple users in multiple roles using multiple
devices and communicating over multiple networks” as presented by Panetta in his
work at [5]
Thus, each 5G-ready application can be modelled as a Service Mesh. More
specifically the service mesh is presented by Morgan [6] as a “dedicated infrastructure
layer for handling service-to-service communication. It is responsible for the reliable
delivery of requests through the complex topology of services that comprise a
modern, cloud native application. In practice, the service mesh is typically
implemented as an array of lightweight network proxies that are deployed alongside
application code, without the application needing to be aware”. This infrastructure
layer comes to tackle a deep issue regarding the real properties of network.
Specifically, Peter Deutsch [7] describes a list of “fallacies”, as a set of the opposite
of rules about distributed computing that people often forget based on the
assumptions that they are making for the underlying network. These fallacies include
the assumption that (i) the network is reliable, (ii) latency is zero, (iii) bandwidth is
infinite, (iv) the network is secure, (v) the topology does not change, (vi) there is one
administrator, (vii) transport cost is zero and (viii) the network is homogeneous. The
removal of these assumptions requires the addition and the satisfaction of many hard
requirements [8], something that is feasible in 5G-enabled environments.
The Service Mesh concept is implemented in similar environments with the use
of a sidecar pattern, where the functionality of each of the components in the mesh is
extended by a sidecar proxy. In general, a sidecar is a service that is coupled to
another service (i.e. an application component) that does not interfere with the
functionalities of the main service but extends its properties. A typical example could
be a monitoring information saver that stores (or even analyses) monitoring
information issued by one or more services. In the proposed approach we take the
advantages of the sidecar paradigm, attach a proxy to each of the components, taking
over the network functionalities of it, regarding interconnection with other
components, abstracting the network view to the component the sidecar is attached to,
in order to build a more efficient service mesh.
Fig. 1. Proxy-to-Proxy communication example
The L7 proxy implements L7VFs (plug in functions that are dynamically loaded
by the intelligent proxy) like load balancing, HTTP filter, HTTP routing, service
discovery, etc. that operate at the Application level, abstracting the network to the
components that are connected to it, making the communication among them more
efficient and easier, as it is depicted in Figure 1.
Moreover, the emergence of cloud computing / programmable infrastructure-as-
a-code paradigm along with the dominance of microservice driven architecture,
generated additional requirements. These are related mainly with the: (i) rapid
provisioning of compute resources, (ii) basic monitoring, (iii) rapid deployment, (iv)
easy to provision storage, (v) easy access to the edge, (vi)
authentication/authorization, and (vii) standardized interfaces (e.g. RPC, HTTP).
The requirements of 5G-ready applications coincide with the aforementioned
cloud-native requirements. Yet they are much more exhaustive, since provisioning of
infrastructure should be “instantaneous”, topology is continuously changing, delay
tolerance is minimum, etc. The concept of this dedicated infrastructure layer is
depicted in Figure 2.
Based on the above, a 5G-ready application is a distributed application consisting
of cloud-native components that rely on a service mesh infrastructure as a mean of
network abstraction. The service mesh per se has to operate on top of a programmable
5G environment. To exploit the service mesh added-value, a 5G full-stack
architecture has to be used [9], which relies on a solid interplay between various
logical layers such as the actual data plane, the service mesh control plane, and the
configured virtualized resources that are offered by the telco provider as a proper slice
Fig. 2. Service mesh paradigm for cloud-native applications
3.2 Proposed 5G-ready application metamodel
As already described, the 5G-ready application metamodel incorporates two
fundamental entities: the chainable component and the 5G-ready application graph,
which are presented in the following paragraphs.
Application component part
We propose a separation between the business logic part of a component from the
layer 4-7 network part of it. We implement a service mesh approach with a dedicated
proxy sidecar attached per component. Thus, in this section we present the “core”
component. For each component, a proxy sidecar will also be utilized. The sidecar
will be exploited by an L7 proxy and communication bus framework, such as Envoy
[11]. To this end, the modelling of the proxy is not required.
The component metamodel includes a set of fundamental complex Type elements
(except from the ‘ComponentIdentifier’ element) that uniquely describe each
component in the entire Service Mesh. These elements are the following as depicted
also in Figure 3: (i) The ‘Distribution’ element, (ii) the ‘ExposedInterface’ element,
(iii) the ‘Configuration’ element, (iv) the ‘Volume’ element, (v) the
‘MinimumExecutionRequirements’ element, (vi) the ‘ExposedMetric’ element, (vii)
the ‘RequiredInterface’ element, and finally (viii) the ‘Capability’ element.
The first complex type element regards the ‘Distribution’ element that encapsulates
the information that is required for fetching an instance of a Component. It contains
information regarding the final image / container of a component and the URI where
the component is located in the repository.
The second complex type element, the ‘ExposedInterface’, is critical since it
describes the exposed interfaces. It is a “one-to-many” relation since a component
might expose several interfaces. It encapsulates the descriptive identifier of the
interface, which is required in order to infer the chainability of dependencies during
the Service Mesh deployment. Furthermore, it contains the classification of the
exposed interface based on its positioning in the 5G network. It can be ACCESS or
CORE. The ACCESS type refers to the UserEquipment-to-component
communication, where the CORE refers to the component-to-component
communication. Moreover, it contains port declaration and an optional choice for the
transport layer protocol. On the other hand, each component requires some inputs.
Thus, the required interface section of the component encapsulates via a “one-to-
many” relation the information regarding the graph link, which links the current
component with another component. Specifically, it encapsulates the identifier of the
component that satisfies the current component input needs and the corresponding
exposed interface identifier. To this end, it should be mentioned that there is also a
descriptive identifier of this logical link (“GraphLink”) between two components.
Next stands the “Configuration” element. This aspect represents a set of
environmental variables that should be provided to the component during
instantiation. In practice, it is a generic collection of key-value pairs to be exploited
for deployment and instantiation.
Fig. 3. High-level view of the component metamodel
The application component also includes the “Volume” element. This element
offers the capability of the Hypervisors to provide storage to a virtual machine (VM)
via volumes. To capture the corresponding cases, the model includes three “children”
for each volume instance. The definition of the type of the volume since if it has been
attached to the guest using one hypervisor type (e.g. Xen), cannot be attached to a
guest that is using another hypervisor type (e.g. vSphere, KVM). This happens due to
the fact that the different hypervisors use different disk image formats. Additionally,
the “Volume” element includes sub-elements for the source and the target of each
Furthermore, a crucial aspect of the component relates to its minimum
requirements that have to be met by the hosting environment for the proper execution.
This complex ‘MinimumExecutionRequirements’ element contains the “VCPU”
element that refers to the minimum number of vCPUs that should be provided by the
hypervisor, the minimum memory (i.e. the “Memory” element) and storage (i.e. the
“Storage” element) and an element regarding the type of the hypervisor that is
preferred (i.e. “Hypervisor” element) which has the following options; either Esxi,
KVM or Xen.
The application component metamodel also includes a section regarding the
metrics that will be reported by the proxy sidecar, the “ExposedMetric”. It is a key-
value structure with the metric identifier as key and the unit of it as value.
Finally, the “Capability” element encapsulates runtime capabilities of the
components that are considered inherent. Such a capability is the scaling of the
Application graph / Service Mesh part
Many chainable components can be combined in order to create a 5G-ready
application graph. As already described, an application graph is essentially a directed
acyclic graph (DAG) that is implemented as a Service Mesh.
As depicted in the figures 4 (a) and 4 (b) below, given the adoption of the service
mesh paradigm, the form of the application metamodel is simple. It contains a
“ServiceMeshIdentifier” for the unique identification of each 5G-ready application, a
“Name” that includes the descriptive name of each Service Mesh. As expected, a
“one-to-many” relation is used to capture the correlation between the Service Mesh
and its components.
While this metamodel may seem simple, it is in fact quite informative. There is
no need for declaring graph links and their constraints, since (i) each graph link
description is encapsulated in each component as it has been analyzed in the previous
subsection of this paper. Specifically, each link is considered as an input required
interface of the component which needs it, and (ii) it is a logical link, and each logical
link will be realized as a network link, with network and compute constraints. These
constraints are incorporated in another metamodel that is exploited by the northbound
Vertical Orchestrator [9]: The Slice Intent metamodel [3]. The figures below depict
the relevant part of the metamodel.
As depicted in Figures 4 (a) and 4 (b) the vertical orchestrator is able to intent
more computational quota for the efficient execution of application plus of minimum
requirements per component and also it is able to define some serious network QoS
constraints per graph link such as delay, jitter, packet loss, throughput.
These capabilities are provided by slice intent metamodel [3] which will
elaborate more in a future paper. In conclusion, it’s important to underline that there is
a direct relation between application graph metamodel and slice intent metamodel
which the first seriously affects the second and otherwise.
(a) (b)
Fig. 4. (a) Slice intent - Resource constraints, (b) Slice intent Graph link QoS constraints
4 Use case
The proposed metamodel as described above, was used in a real-life deployment
scenario. The orchestration of the testbed was done by a 5G Vertical Application
Orchestrator (VAO), fully aligned with the proposed model.
The testbed is located in the TNT-lab at DITEN of University of Genoa. It consists of
both radio access and virtualized infrastructure parts. The business scenario regards a
5G-enabled emergency response pilot provided with the iMON product suite [21] for
real time intervention monitoring and critical infrastructure protection.
The deployed application was placed in two parallel instances in different data
centers. The two datacenters during the whole time were fully synced, to avoid any
upcoming issues in case of shutdown. Thus, for the full synchronization of the two
instances, between the different locations, the database (DB) component and the
binary large objects (BLOB) storage components of the application were
communicating continuously.
The deployed application consisted of three application components; a database
system that was connected to a PHP service and a BLOB connected to the PHP
Regarding the database system the proposed model was fulfilled with information,
including the (a) ‘ExposedInterface’ element that presented the chainable interface to
the PHP component, (b) the ‘Capability’ element that stated that this component is
vertically scalable, (c) the ‘Distribution’ element regarding the image of a MySQL
service used, and (d) the ‘MinimumExecutionRequirements’ element with 2x CPU
cores, 2GB of RAM, and 20GB of Disk. For the PHP business logic (BL) service in
the shape of a tactical dashboard, the described model contained information related
to (a) the ‘RequiredInterface’ element to the DB and BLOB components, (b) the
‘ExposedInterface’ element that presented the two chainable interfaces to the DB and
the BLOB components, (c) the ‘Capability’ element stating that this component was
horizontally scalable, (d) the ‘Distribution’ element providing information about the
Apache web server image used, also hosting the proprietary PHP-based page, and (e)
the ‘MinimumExecutionRequirements’ element with 2x CPU cores, 2GB of RAM,
and 10GB of Disk. Finally, regarding the BLOB the model contained information
related to (a) the ‘ExposedInterface’ element that offered a chainable interface to the
PHP BL component, (b) the ‘Capability’ element stating that it was vertically
scalable, (c) a ‘Distribution element containing information regarding the SAMBA
service image used, and (d) the ‘MinimumExecutionRequirements’ element with 2x
CPU cores, 2GB of RAM, 40GB of Disk.
More information regarding the slice intent descriptor for the constraints of access
links and NFV-based components of the scenario were also described, but are not in
the scope of the current paper.
The execution of the application was done without any issues emerging. This
happened due to the fact that the model was very informative, and the orchestrator
was fully aligned with it. So even in cases where problems could arise (e.g. a stress-
tests were executed) there were no problems causing it to shut down or arise
deployment issues.
5 Conclusions
In this paper we provided the specification of a 5G-ready application graph as well as
the relevant metamodel. The metamodel presented contains valuable information
regarding the application graph and the components constituting it, containing the
mandatory elements that are used for deployment and instantiation of the components
and thus the overall application.
The next step in our work is to create a suite of supporting mechanisms to facilitate in
the whole management process. This suite consists of three major supporting
mechanisms, (i) the performance estimator, (ii) the graph-level aggregator and (iii) the
recommendation engine. The first mechanism, meaning the performance estimator,
will be used for the provision of resource estimations regarding the application
components in order to facilitate the infrastructure orchestrator on the better
deployment and runtime adaptation. The graph-level aggregator will be responsible
for collecting all the performance estimates per application component and produce
aggregated results for the complete application graph. The last mechanism (i.e. the
recommendation engine) will be responsible for proposing components during the
composition of an application graph, based on prior usage of the components similar
to [22], as well as the performance estimates.
In addition, there will be three validation mechanisms, the chainability evaluator, the
configurability checker and the validation optimizer. The first mechanism regards the
evaluation of the chainability of a component in an application graph, that will be
used to evaluate whether the connected components can be chained or not, based on
the interfaces that are exposes by an application component and the required ones
from the components with which it is connected. The configurability checker will be
responsible for validating whether an application component exposes its configuration
parameters and if it’s adequate to alter its configuration during runtime if required.
Finally, the optimizer mechanism will assist on the more rapid evaluation of each
application component with respect to the validation mechanisms as described above.
In essence, this mechanism will be in charge of checking if each component on the
application graph is already validated or not and if it has there will be no need for re-
validation. Note though, that even if an application component has already been
evaluated in terms of chainability, it may not be chainable in another application
graph, since the topology of the graph plays significant part.
6 Acknowledgement
The publication of this paper has been partly supported by the University of Piraeus
Research Center and by the European Union’s Horizon 2020 research and innovation
program under grant agreement No 761898 project Matilda.
1. A. Gupta, R. K. Jha, “A Survey of 5G Network: Architecture and Emerging
Technologies,” IEEE Access, vol. 3, pp. 1206-32, 2015
2. The 12-factor methodology. Available online at:
3. D1.4 MATILDA Network-aware Application Graph Metamodel (Network Slice
Intent and Slice Instance Metamodel). Available online at: http://www.matilda-
4. Kostas Katsalis, Navid Nikaein , Eryk Schiller, Romain Favraud, Torsten Ingo Braun,
“5G Architectural Design Patterns,” 2016 IEEE ICC Wksps., 2016, pp. 3237.
5. K. Panetta, “Top 10 Strategic Technology Trends for 2017”. Available online at:
6. W. Morgan, “What’s a service mesh? And why do I need one?,” Available online at:
7. P Deutsch, “Fallacies of distributed computing,” White Paper, wikipedia Google
Scholar, 1995
8. P. Calçado, “Pattern: Service Mesh”. Available online at:
9. D1.1 MATILDA Framework and Reference Architecture. Available online at:
10. Envoy’s blog, “Service mesh data plane vs. control plane”. Available online at:
11. Envoy (an open source edge and service proxy) docs. Available online at:
12. Cloud Native Computing Foundation. Available online at:
13. Juju Orchestrator. Available online at:
14. K. Tsakalozos, C. Johns, K. Monroe, P. VanderGiessen, A. Mcleod and A. Rosales,
"Open big data infrastructures to everyone," 2016 IEEE International Conference on
Big Data (Big Data), Washington, DC, 2016, pp. 2127-2129.
15. ARCADIA Framework. Online at:
16. P. Gouvas, E. Fotopoulou, A. Zafeiropoulos, C. Vassilakis, “A Context Model and
Policies Management Framework for Reconfigurable-by-design Distributed
Applications,” Procedia Computer Science, Volume 97, 2016, Pages 122-125.
17. Symvoulidis, C., Tsoumas, I., & Kyriazis, D. (2019, July). Towards the Identification
of Context in 5G Infrastructures. In Intelligent Computing-Proceedings of the
Computing Conference (pp. 406-418). Springer, Cham.
18. Open-source MANO. Online at:
19. OSM Information Model, 2016. Online at:
20. Hugo Bruneliere, Zakarea Al-Shara, Frederico Alvares, Jonathan Lejeune, Thomas
Ledoux. “A Modelbased Architecture for Autonomic and Heterogeneous Cloud
Systems,” Proceedings of the 8h International Conference on Cloud Computing and
Services Science (CLOSER 2018), Funchal, Portugal, pp.201-212.
21. qMon. Online at:
22. Tsoumas, I., Symvoulidis, C., & Kyriazis, D., Learning a Generalized Matrix from
Multi-Graphs Topologies towards Microservices Recommendations,” Submitted for
publication, 2019
ResearchGate has not been able to resolve any citations for this publication.
Full-text available
The evolution of communication networks, bringing the fifth generation (5G) of mobile communications in the foreground, gives the vertical industries opportunities that were not possible until now. Flexible network and computing infrastructure management can be achieved, hence bringing more freedom to the service providers, to maximize the performance of their computing resources. Still, challenges regarding the orchestration of these resources may arise. For this reason, an engine that can recognize possible factors that might affect the use of these resources and come up with solutions when needed in real-time, is required. In this paper, we present a novel Complex Event Processing engine that is enriched with Machine Learning capabilities in order to be fully adaptive to its environment, as a solution for monitoring application components deployed in 5G infrastructures. The proposed engine utilizes Incremental DBSCAN to identify the normal behavior of the deployed services and adjust the rules accordingly.
Conference Paper
Full-text available
Over the last few years, Autonomic Computing has been a key enabler for Cloud system's dynamic adaptation. However, autonomously managing complex systems (such as in the Cloud context) is not trivial and may quickly become fastidious and error-prone. We advocate that Cloud artifacts, regardless of the layer carrying them, share many common characteristics. Thus, this makes it possible to specify, (re)configure and monitor them in an homogeneous way. To this end, we propose a generic model-based architecture for allowing the autonomic management of any Cloud system. From a "XaaS" model describing a given Cloud system, possibly over multiple layers of the Cloud stack, Cloud administrators can derive an autonomic manager for this system. This paper introduces the designed model-based architecture, and notably its core generic XaaS modeling language. It also describes the integration with a constraint solver to be used by the autonomic manager , as well as the interoperability with a Cloud standard (TOSCA). It presents an implementation (with its application on a multi-layer Cloud system) and compares the proposed approach with other existing solutions.
Full-text available
The design and development of distributed applications consisting of microservices is an emerging pattern, considering the advantages associated with the management of self-deployable and orchestratable components as well as the adoption of a DevOps culture in cloud applications deployment and management. In this position paper, we present a context model for representing the entire lifecycle of reconfigurable-by-design distributed applications consisting of microservices and denoted in the form of a service graph. Based on the context model, we describe a policies management framework targeted at service providers for managing deployment and orchestration aspects of such applications over a programmable infrastructure.
Full-text available
In the near future, i.e., beyond 4G, some of the prime objectives or demands that need to be addressed are increased capacity, improved data rate, decreased latency, and better quality of service. To meet these demands, drastic improvements need to be made in cellular network architecture. This paper presents the results of a detailed survey on the fifth generation (5G) cellular network architecture and some of the key emerging technologies that are helpful in improving the architecture and meeting the demands of users. In this detailed survey, the prime focus is on the 5G cellular network architecture, massive multiple input multiple output technology, and device-to-device communication (D2D). Along with this, some of the emerging technologies that are addressed in this paper include interference management, spectrum sharing with cognitive radio, ultra-dense networks, multi-radio access technology association, full duplex radios, millimeter wave solutions for 5G cellular networks, and cloud technologies for 5G radio access networks and software defined networks. In this paper, a general probable 5G cellular network architecture is proposed, which shows that D2D, small cell access points, network cloud, and the Internet of Things can be a part of 5G cellular network architecture. A detailed survey is included regarding current research projects being conducted in different countries by research groups and institutions that are working on 5G technologies.
This paper presents a methodology that combines latent factor models with graph-based models. The proposed recommendation system identifies a recommended item as a node of a graph. More specifically, the topology of the graph and the paths between the nodes are considered as critical features regarding the associations between them. Furthermore, in the current approach, these structural features are considered as feedback. These structural features are extracted from a pool of several application graphs which are afterwards generalized into a unified matrix of proximities. The main reason for the use of this structural feedback is to generate recommendations and discover unobserved relations using matrix factorization techniques. The approach is tested on a data set that consists of cloud-native microservices graphs.
Conference Paper
The evolution of big data has increased the complexity of the respective software. Big data infrastructures require progressively more time and effort to setup, configure, maintain and integrate with existing systems. In absence of a big data “expert”, users are often discouraged from using such solutions. The option of consuming big data infrastructures as a service seems to be a viable one, yet it is not without drawbacks. Such an option a) is costly, b) often locks users down to a vendor, and c) is limited to what the vendor decides to make available In this paper we present Juju, an open source service modelling approach by Canonical that addresses the above shortcomings. With Juju users can deploy and maintain their infrastructures to a rich variety of target environments that include almost any cloud, local machines (using containers & VMs), bare metal systems and any remote machine the user might have ssh access to. The Juju big data community makes sure that deploying big data infrastructures is as simple as running “juju deploy hadoop”, while interfaces among infrastructures allow for easy system integration. In this work we also show how the operational knowledge of complex software such as Apache Spark can be encapsulated in a few hundreds lines.
Conference Paper
In this work, we present novel Architectural Design Patterns towards open, cloud-based 5G communications. We provide a brief classification of technologies that cannot be ignored in the design process of 5G systems and illustrate how a new technological added value can be created, when current methodologies, design paradigms, as well as design patterns and their extensions are properly exploited in efficient Radio Access Network (RAN) architectures. We believe that in many cases, the required technology is already there; nevertheless the correct approach has to be worked out and placed within an appropriate context, especially in the case of the integration of complex RAN systems. The enhancements in RF optimization, the progress in cloud computing, Software Defined Networks (SDN) and Network Function Virtualization (NFV), new design concepts such as Network Slicing have to become part of the RAN design methodology. Diverse architectural concepts should break existing stereotypes to pave the way towards the true 5G system integration.
What’s a service mesh? And why do I need one?
  • W Morgan
W. Morgan, "What's a service mesh? And why do I need one?," Available online at:
Pattern: service mesh
  • P Calçado
P. Calçado, "Pattern: Service Mesh". Available online at:
Top 10 Strategic Technology Trends for
  • K Panetta
K. Panetta, "Top 10 Strategic Technology Trends for 2017". Available online at: RW%2B53QE2hzw%3D%3D