Conference PaperPDF Available

ClouNS - A Cloud-native Application Reference Model for Enterprise Architects


Abstract and Figures

The capability to operate cloud-native applications can create enormous business growth and value. But enterprise architects should be aware that cloud-native applications are vulnerable to vendor lock-in. We investigated cloud-native application design principles, public cloud service providers, and industrial cloud standards. All results indicate that most cloud service categories seem to foster vendor lock-in situations which might be especially problematic for enterprise architectures. This might sound disillusioning at first. However, we present a reference model for cloud-native applications that relies only on a small subset of well standardized IaaS services. The reference model can be used for codifying cloud technologies. It can guide technology identification, classification, adoption, research and development processes for cloud-native application and for vendor lock-in aware enterprise architecture engineering methodologies.
Content may be subject to copyright.
ClouNS - A Cloud-native Application Reference Model for Enterprise Architects
Nane Kratzke
ubeck University of Applied Sciences
Center of Excellence CoSA
ubeck, Germany
e Peinl
Hof University of Applied Sciences
Institute of Information Systems
Hof, Germany
Abstract—The capability to operate cloud-native applications
can generate enormous business growth and value. But enter-
prise architects should be aware that cloud-native applications
are vulnerable to vendor lock-in. We investigated cloud-native
application design principles, public cloud service providers,
and industrial cloud standards. All results indicate that most
cloud service categories seem to foster vendor lock-in situ-
ations which might be especially problematic for enterprise
architectures. This might sound disillusioning at first. However,
we present a reference model for cloud-native applications
that relies only on a small subset of well standardized IaaS
services. The reference model can be used for codifying cloud
technologies. It can guide technology identification, classifica-
tion, adoption, research and development processes for cloud-
native application and for vendor lock-in aware enterprise
architecture engineering methodologies.
Index Terms—cloud computing, container, cloud-native ap-
plication, elastic platform, enterprise architecture, reference
model, service oriented architecture, transferability, microser-
vice, vendor lock-in
1. Introduction
Even for small companies, it is possible to generate enor-
mous economical growth and business value by provid-
ing cloud-native services or applications. E.g., Instagram
proofed successfully that it was able to generate exponential
business growth and value in a very short amount of years.
At the time of being bought by Facebook for 1 billion
USD, Instagram had only a headcount of about 20 persons,
was only two years old, but operated already a world wide
accessible and scalable social network for image sharing
(hosted by Amazon Web Services, AWS) without owning
any data center or any noteworthy IT assets. On the other
hand, if AWS had to shutdown their services at that time
due to an insolvency or something alike, it is likely that
Instagram had been carried away by such an event as well.
The reader should consider, that it took years for Instagram’s
cloud engineers to transfer their services from the AWS
cloud infrastructure completely into Facebook’s data centers.
And this transfer was accompanied by several noteworthy
service outages.
Enterprise architects should be aware of such kind of
vendor lock-in situations and should try to avoid them by
design. According to Pahl et al. cloud computing must
implement universal strategies regarding standards, interop-
erability and portability to reduce vendor lock-in situations.
Open standards are of critical importance and need to be
embedded into interoperability solutions [1]. However, stan-
dardization processes are slow. We found that 80% of pro-
vided public cloud services are not even considered in cloud
standards like CIMI [2] or OCCI [3], [4]. This might sound
disillusioning. But it might be the key to handle vendor lock-
in pragmatically, if we simply accept this as a fact. At last
it means, that there is a small part of standardized cloud
computing. We propose to use this ”isle of felicity” as the
foundation of a portable cloud runtime environment. Satzger
et al. developed already such a vision for a vendor lock-in
free cloud. ”Ameta cloud [...] incorporates design time
and runtime components. This meta cloud would abstract
away from existing offerings technical incompatibilities, thus
mitigating vendor lock-in. It [...] supports an applications
initial deployment and runtime migration.” [5]. They further
postulated that ”most of the basic technologies necessary to
realize the meta cloud already exist, yet lack integration”.
Our presented ClouNS reference model is in accordance
with this meta cloud concept but it is much more concrete
than visionary. It integrates existing container solutions (like
Docker), existing cloud infrastructure bridging environments
(scalable and container based cloud runtime environments
like Mesos/Marathon or Kubernetes), existing microservice
architecture approaches and existing cloud-native applica-
tion patterns into one integrated concept which considers
vendor lock-in awareness in each conceptual layer. All these
identified building blocks of cloud-native applications can
be valuable components of cloud-based and vendor lock-in
aware enterprise architectures.
2. Outline and research methodology
Our research methodology is shown in Figure 1. We per-
formed a systematic mapping study on cloud-native appli-
cations to get a better understanding what cloud-native ap-
plications (CNA) exactly are. Basic insights are summarized
in Section 3. Because cloud-native applications are very
978-1-4673-9933-3/16/$31.00 ©2016 IEEE
Figure 1. Research methodology
vulnerable to vendor lock-in, we performed additionally
a review on cloud standardization approaches. Section 4
summarizes how vendor lock-in emerges in cloud com-
puting. Both reviewing steps have been accompanied by
action research in concrete projects or by having cloud-
native application engineering approaches by practitioners
under research surveillance. Our resulting and proposed
reference model ClouNS (cloud-native application stack) is
presented in Section 5 and relies only on a small subset
of standardized IaaS services to avoid vendor lock-in. We
evaluated this reference model in Section 6 using a concrete
project from our action research activities and show that
the presented ClouNS reference model covers more aspects
of cloud-native applications than any other current cloud
3. Cloud-native applications
It is common sense that cloud-native applications are de-
veloped intentionally for the cloud. However, there is no
common definition that explains what that exactly means.
Our literature review1on cloud-native applications turned
out, that there is a common but unconscious understanding
across all analyzed papers. Cloud-native applications (CNA)
should be build according to corresponding CNA principles
(operated on automation platforms providing softwarization
of infrastructure and network, having migration and interop-
erability aspects in mind). These principles enable to build
CNA architectures with specific and desirable CNA prop-
erties (horizontal scalablity, elasticity, resiliency, isolated
states, to name some of the most mentioned properties).
Accompanying CNA methodologies are often pattern based.
The following insights are the most valuables from authors’
point of view.
1. Currently prepared for a separate publication.
Fehling et al. propose that a cloud-native application
should be IDEAL. It should have an isolated state,is
distributed in its nature, is elastic in a horizontal scaling
way, operated via an automated management system and
its components should be loosely coupled [6]. According
to Stine there are common motivations for cloud-native
application architectures [7] like to deliver software-based
solutions more quickly (speed), in a more fault isolating,
fault tolerating, and automatic recovering way (safety), to
enable horizontal (instead of vertical) application scaling
(scale), and finally to handle a huge diversity of (mobile)
platforms and legacy systems (client diversity).
These common motivations are adressed by several
application architecture and infrastructure approaches [8]:
Microservices represent the decomposition of monolithic
(business) systems into independently deployable services
that do ”one thing well” [9], [10]. The main mode of
interaction between services in a cloud-native application
architecture is via published and versioned APIs (API-
based collaboration). These APIs often follow the HTTP
REST-style with JSON serialization, but other protocols and
serialization formats can be used as well. Single deployment
units of the architecture are designed and interconnected
according to a collection of cloud-focused patterns like the
twelve-factor app collection [11], the circuit breaker pattern
[12] or cloud computing patterns [6]. And finally, self-
service agile infrastructure platforms are used to deploy
and operate these microservices via self-contained deploy-
ment units (containers). These platforms provide additional
operational capabilities on top of IaaS infrastructures like
automated and on-demand scaling of application instances,
application health management, dynamic routing and load
balancing as well ass aggregation of logs and metrics.
These aspects lead us to the following definition:
Acloud-native application is a distributed, elastic and
horizontal scalable system composed of (micro)services
which isolates state in a minimum of stateful compo-
nents. The application and each self-contained deploy-
ment unit of that application is designed according to
cloud-focused design patterns and operated on a self-
service elastic platform.
4. Approaches dealing with vendor lock-in
Vendor lock-in is defined to make a customer dependent on
a vendor for products and services, unable to use another
vendor without substantial switching costs [13], [14]. This
section will explain how vendor lock-in emerges and how it
is typically addressed looking at relevant cloud computing
use cases identified by [15].
Vendor lock-in in cloud computing. A commodity de-
scribes a class of demanded goods (in case of IaaS com-
puting, storage and networking services) without substantial
qualitative differentiation. The market treats instances of
the goods as (nearly) equivalent. Or more simple: a virtual
server provided by Google Compute Engine (GCE) can
easily being replaced by a server provided by Amazon Web
Services (AWS, i.e. system portability in NIST terms), as
described in use case CCUC 3 [15] and one can even find
very similar instances regarding resources and performance
[16]. Therefore, IaaS provides a commodity service.
On the other hand, switching from one SaaS service
provider to another one (CCUC 1, [15]) or changing the
middleware (PaaS, CCUC 2) is in most cases not as easy
as buying coffee from a different supplier. While CCUC 1
is about finding a different provider with the same SaaS of-
fering (e.g., hosted SharePoint) and migrating configuration
and data (data portability in NIST terms), this paper con-
centrates on CCUC 2 and the respective tasks of application
architects to build their cloud-native application on services
of one provider, that are easily replacable by equivalent
services of other providers (application portability in NIST
terms [15]). The core components of these distributed sys-
tems like virtualized server instances and basic networking
and storage can be deployed using commodity services.
However, further services needed to integrate these virtual-
ized resources in an elastic and scalable manner are often not
considered in standards. Services like load balancing, auto
scaling or message queuing systems are needed to design
an elastic and scalable cloud-native system on any cloud
service infrastructure. But especially these services are not
considered consequently by current cloud standards (see Ta-
ble 2 and [17]). All cloud service providers try to stimulate
cloud customers to use these non-commodity convenience
services in order to bind them to their infrastructure. So,
the following strategies of top-down standardization, open
source bottom-up solutions and formalized deployment ap-
proaches can be identified to overcome this kind of vendor
lock-in. For a more detailed discussion we refer to [18].
Industrial Top-Down Standardization Approaches. We
cover only the following few approved service interoper-
ability standards [19]. For a more complete survey on cloud
computing standards we refer to [1].
Cloud Infrastructure Management Interface (CIMI)
specification [2] describes the model and protocol for man-
agement interactions between a cloud Infrastructure as a Ser-
vice (IaaS) provider and the consumers. The basic resources
of IaaS (machines, storage, and networks) are modeled with
the goal of providing consumer management access to an
implementation of IaaS and facilitating portability between
cloud implementations that support the specification. CIMI
is accompanied by the Open Virtualization Format (OVF).
OVF describes an ”open, secure, portable, efficient and
extensible format for the packaging and distribution of
software to be run in virtual machines” [20].
The Open Cloud Computing Interface (OCCI)[3], [4] is
a RESTful Protocol and API. OCCI was originally initiated
to create a remote management API for IaaS services,
allowing for the development of interoperable tools for
common tasks including deployment, autonomic scaling and
monitoring. It has since evolved into a flexible API with
a focus on interoperability and offering a high degree of
The Cloud Data Management Interface (CDMI)[21] is
used to create, retrieve, update, and delete objects in a cloud
via a RESTful API. The CDMI reference model focuses
Storage as as Service and covers block storage, file system
storage, object storage, table-based storage and storage for
large scale queueing systems. Due to its storage focus it is
more limited than CIMI and OCCI.
There are further accompanying drafts, interoperability
standards, guides and working groups like [22], [23] having
less concrete working results than the already mentioned
standards. So, we did not list them in Section 6 (Table 2)
for our evaluation.
Open-Source Bottom Up Approaches. Open source bot-
tom up approaches try to harmonize the API of cloud
providers with an own abstraction (e.g., Deltacloud,,
jClouds, Apache Libcloud, see [24]). They try to do the
same like the industrial standardization approach but apply a
bottom up strategy. These kind of libraries provide (limited)
access to 15 - 30 cloud service providers and support: Cloud
Servers and Block Storage, Object Storage and CDN, Load
Balancing and DNS as a Service, Container Services. In fact,
that is very similar compared to the coverage of industrial
Formalized Deployment Approaches. Several research ap-
proaches tried not to focus the cloud infrastructure as object
of standardization but to standardize the deployment of
complex systems. This is often done by defining descriptive
(often XML-based) deployment languages [25], [26], [27],
[28]. However, these kind of languages are often limited
to static (non elastic) deployments. To handle elasticity
these approaches need something like a runtime environ-
ment responsible for auto-scaling and load balancing. All of
these research directions were valuable and contributed to
standardization approaches like TOSCA [29]. More recent
research approaches are SALSA focusing dynamic config-
uration of cloud services [30], SPEEDL focusing an event-
based language to define the scaling behavior of cloud
applications [31] or SYBL as an extensible language for
controlling elasticity in cloud applications [32].
Summary. The release cycles of new cloud services over
the last 10 years show that standardization processes are
far slower than cloud service development and deployment
processes of major public cloud providers. This phenomenon
is not new in information technology and often fosters
establishing so called de facto standards like MS-DOS and
IBM PCs in the 1980’s, Windows/MS-Office or PDF in the
1990’s, Java Virtual Machine in the 1995’s, Android and
iOS in 2010’s, just to name a few.
All reviewed cloud standards and open-source bottom up
approaches concentrate on a very small but basic subset of
popular cloud services: compute nodes, storage (file, block,
object), networking, logging and (static) system deploy-
ments. Also deployment approaches are defined against this
infrastructure level of abstraction. These kind of services are
often subsumed as IaaS and build the foundation of cloud
services and therefore cloud-native applications. All other
service categories might foster vendor lock-in situations
if they are not standardized and can not be provided in
a form to be deployed on any ”portable cloud runtime
environment”. This all might sound disillusioning. But in
consequence, the basic idea of a cloud-native application
stack used for enterprise architectures should be to use
only this small subset of well standardized IaaS services
as founding building blocks (see Section 5).
5. The cloud-native application stack
The Open Systems Interconnection model (OSI model) is
a well accepted conceptual model that characterizes and
standardizes the communication functions of a communi-
cation system without regard to their internal structure and
technology [33]. Its goal is the interoperability of diverse
communication systems with standard protocols. The model
partitions a communication system into abstraction layers.
Although the OSI model can not be applied directly to
cloud service interoperability, the underlying principles of
the layered architecture can be applied to a cloud stack as
1) Create so many layers as necessary but not more.
2) Create a boundary at a point where the description of
services can be small and interactions across boundaries
are minimized.
3) Create separate layers to handle functions that are differ-
ent in the process performed or the technology involved.
4) Collect similar functions into the same layer.
5) Create layers of localized functions. A layer must be
totally redesignable to take advantage of new advances
in architectural, hardware or software technology without
changing services expected from and provided to the
adjacent layers.
6) Allow changes of functions or protocols to be made
within a layer without affecting other layers.
7) Create for each layer, boundaries with its upper and lower
layer only.
The same principles were successful in the past to structure
a vast amount of fast evolving network technologies, tools
and standards. Why should this not be working for the cloud
computing domain which is characterized by a vast amount
of fast evolving cloud technologies, tools and standards? Our
reference model is intentionally designed to be enterprise
architecture framework agnostic. Due to the great amount
of EA frameworks, it should be composable with existing
approaches like TOGAF, FEA, NAF, etc. [34]. However,
we will show exemplary (if appropriate) how our approach
relates to EA frameworks like TOGAF for instance.
To have multiple view points on the same object was
made popular by the Zachman Framework [35] and has
been adapted successfully by other architecture frameworks
and methodolgies. Obviously the same is true for cloud
computing. We can look from a service model point of view
(IaaS, PaaS, SaaS), a deployment point of view (private,
public, hybrid, community cloud) on cloud computing as it
is done by [36]. Or we can look from an actor point of view
(provider, consumer, auditor, broker, carrier) or a functional
point of view (service deployment, service orchestration,
service management, security, privacy) as it is done by [37].
Points of view are particular useful to split problems into
concise parts. However, the above mentioned view points
are useful from service provider point of view but not
from cloud-native application engineering point of view.
From an engineering point of view it would be more useful
to have views on technology levels involved and applied
in cloud-native application engineering as it is often done
by practitioner models. However, these practitioner models
have been only documented in some blog posts2anddonot
expand into any academic papers as far as the authors know.
Therefore, we propose the following four basic view points
for ClouNS (see Table 1 and Figure 2) which can be aligned
to TOGAF concepts like business, information systems, and
technology architecture:
(1) Node centric view point (aka IaaS). This is a view
point being familiar for engineers who are developing clas-
sical client server architectures. The server parts are often
deployed onto a single compute node (a server). This is
how IaaS is understood most of the times. IaaS deals with
deployment of isolated compute nodes for a cloud consumer.
It is up to the cloud consumer what it is done with these
isolated nodes (even if there are provisioned hundreds of
them). EA frameworks like TOGAF covering this view point
often with a technology architecture.
(2) Cluster centric view point (aka CaaS). This is a view
point being familiar for engineers who are dealing with
horizontal scalability across nodes. Clusters are a concept
to handle many nodes as one logical compute node (a clus-
ter). Such kind of technologies are often the technological
backbone for PaaS solutions and portable cloud runtime en-
vironments because they are hiding complexity (of hundreds
or thousands of single nodes) in an appropriate way. We call
these platforms portable because they can be deployed on
any IaaS infrastructure. Recently the term CaaS (Container
as a Service) is more and more used to describe such solu-
tions if they are using container technologies under the hood.
Furthermore, we have to consider scalable cluster storage
solutions necessary for stateful services like Database as a
Service approaches. According to TOGAF this view point
is reflected mainly in the technology architecture as well.
Additionally, CaaS realizes the foundation to define ser-
vices and applications without reference to particular cloud
services or cloud infrastructures and therefore provides the
basis to avoid vendor lock-in.
(3) Service centric view point (aka PaaS). This is a view
point familiar for application engineers dealing with Web
services in service-oriented architectures (SOA). Of course,
(micro)services have to be deployed on and operated by
2. Practicioner Blog Posts:
Jason Lavigne, ”Don’t let aPaaS you by - What is aPaaS and why Mi-
crosoft is excited about it”, see https://atjasonunderscorelavigne.wordpress.
com/2014/01/27/dont-let-apaas-you-by/ (last access 1th May 2016)
Johann den Haan, ”Categorizing and Comparing the Cloud
Landscape”, see
categorize-compare-cloud-vendors/ (last access 1th May 2016)
Viewpoint Layer (Sub)layer Name Main Purpose Examples Example Standards
SaaS (6) Application Application Providing End User Functionality
PaaS (5) Service Functional Services Providing Functional Services RabbitMQ, Hadoop AMQP
All Purpose Services Providing Distrib. Sys. Patterns SpringCloud
Storage Services Providing Storage Services S3, Swift, RADOS CDMI
Providing Database Services RDS SQL
CaaS (4) Cluster Container Orchestrator Providing Continual Elasticity Kubernetes, Marathon TOSCA
Overlay Network Bridging IaaS Networks Flannel, Weave, Calico
Cluster Scheduler Scaling Cluster Swarm, Mesos, ECS
Bridging IaaS Infrastructures
Clustered Storage Providing Scalable Storage Gluster FS, Ceph NFS, CIFS, WebDav
IaaS (3) Container Host Container Executing Deployment Units Docker, Rkt OCI
Operating System Operating Hosts Linux, OS X, Windows POSIX
(2) Virtual Host Virtual Infrastructure Providing Virtual Machines EC2, GCE, OS, ESX OVF, OCCI, CIMI
(1) Physical Host Physical Infrastructure Providing Host Machines Bare Metal Machines
single nodes. However, all necessary and complex orches-
tration of these single nodes is delegated to a cluster (cloud
runtime environment) providing a platform as a service
(PaaS). According to TOGAF this layer is covered mainly in
the information systems architecture. Due to the fact that mi-
croservices are aligned to business capabilities, this fits very
well with the TOGAF intent, that an application architecture
should mainly identify ”logical groups of capabilities that
manage data and support business functions”.
(4) Application centric view point (aka SaaS). This is
a view point being familiar for end-users of cloud services
(or cloud-native applications). These cloud services are com-
posed of smaller cloud services being operated on clusters
formed of single compute and storage nodes. The cloud
provision model SaaS falls into this category. However, most
of the times – and on this level – cloud users are not in-
terested in underlying technological details and layers, they
are thinking in business processes, business services, and
business functions. Therefore, this layer is covered mainly in
the TOGAF information systems (application) architecture.
Due to the fact, that it is most of the times business use-case
oriented it has much clearer relationships to business goals,
functions, services, and processes identified in a TOGAF
business architecture.
5.1. Node-centric view point aka IaaS
A node centric view on cloud computing comprises sev-
eral layers to handle the physical infrastructure, the virtual
infrastructure (main outcome of IaaS services), the operat-
ing systems layer provided inside virtual machines (VMs)
and the currently popular container layer providing self-
contained deployment units (so called containers). Although
currently it can be considered good practice to operate con-
tainers on VMs, ongoing developments to increase security
and encapsulation of containers make it probable that the
virtualization layer will loose importance in the future as
containers will directly run on the OS atop the physical
hardware (like Google is said to do already).
Layer 1: Physical Host. This layer is the cloud computing
analogy for the physical media of the OSI model. Due to the
fact that this is normally hidden and only of direct access
to a cloud provider, we will not cover this layer in detail.
Layer 2: Virtual Host. This layer is the domain of IaaS
solutions. It is mainly covered by cloud standards like CIMI,
OCCI, OVF. So, Layer 2 is one of the best industry standard-
ized layers in the presented reference model. Typical public
or private cloud services are the EC2 service by AWS ,GCE
by Google,Virtual Machines service by Azure or Nova by
OpenStack. This layer provides virtual machines, which are
connected by a network of the cloud provider. The machines
can be configured to be accessible from public internet via
configurable IP-source and port ranges. The machines can be
assigned disk storage provided by the cloud infrastructure.
Layer 3: Container Host. In most cases, standard oper-
ating systems are installed on virtual machines to operate
the node and to install and configure additional arbitrary
software packages. The most prominent operating system
related standard might be the POSIX standard family [38].
Typical operating systems used in cloud computing are often
Linux/Unix systems, but arbitrary operating systems are
possible. There are some Linux based OS like CoreOS or
Atomic especially configured for providing only container
runtime environments (see [39] for more), but machines on
Layer 3 can be used as all purpose nodes. However, there is
a trend to use container technologies to simplify deploying
and minimize incompatibilities of different applications run-
ning on the same host. Container solutions, notably Docker
[39], provide a self-contained standard runtime,image
format,andbuild system for operating system containers
deployable to any Layer 3 machine. The open container
initiative (OCI, [40]) is an open governance structure with
the purpose of creating open industry standards around
container formats and runtime environments focusing this
5.2. Cluster view point aka CaaS
Layer 4: Cluster. A cluster centric view on cloud computing
comprises several sublayers to integrate multiple Layer 3
container hosts into one single and higher level logical
Figure 2. The Anatomy of the Cloud-Native Stack (ClouNS)
container cluster (Container as a Service, CaaS [41]). These
technologies are used as self-service agile infrastructure
platforms [7] and they provide a portable cloud runtime
environment for cloud-native applications. These platforms
are complex, so we have to distinguish different compo-
nents of such a container cluster. Apache Mesos [42] is a
prominent type representative here. It has been successfully
operated for years by companies like Twitter or Netflix
to consolidate hundreds of thousands of compute nodes.
More recent approaches are Docker Swarm and Google’s
Kubernetes, the open-source successor of Google’s internal
Borg system (see [43] and [39] for an overview). There
are a lot of variants of deploying these tools. It is possible
to deploy Kubernetes on Mesos or on Swarm. By default,
Kubernetes uses CoreOS/fleet as a cluster scheduler. And
all technologies providing a clustering technology around
container. But what is the difference?
(1) Scheduler. From our point of view there are three
main benefits of cluster schedulers like Docker Swarm or
Apache Mesos, starting with the integration of single nodes
(container hosts) into one logical cluster (1st benefit).
This integration can be done within an IaaS solution (for
example only within AWS) and is mainly done for com-
plexity management reasons. However, it is possible to
deploy such cluster schedulers across public and private
cloud infrastructures (for example deploying some Layer
3 container hosts of the cluster to AWS,sometoGCE and
some to an on-premise OpenStack infrastructure). Even if
the container cluster is deployed across different cloud
service providers (2nd benefit) it can be accessed as logical
single cluster, which is of course a great benefit from a
vendor lock-in avoiding (3rd benefit) point of view. Our
own research deals with aspects on this layer [44].
(2) Overlay Network. Even if only a single cloud
service provider is involved, you need an easy way to
communicate between containers on different hosts. That
is why overlay networks like Weave [45], Calico [46]
or flannel gained substantial interest. Weav e and Calico
can be integrated easily into Docker Swarm (replacing the
default libnetwork overlay solution). Flannel [47] is well
integrated with the CoreOS/fleet cluster scheduler. Industrial
standardization is quite rare on this layer. The authors are
not aware of any cloud-specific applicable standard (except
general networking standards).
(3) Orchestrator. While cluster schedulers focus on the
infrastructure unification, container orchestrators focus the
payload which is being deployed to the cluster. Kubernetes
[43] is a good example that container orchestrators can use
basic deployment capabilities of cluster schedulers to deploy
applications in a distributed and containerized form. There
are several approaches how to operate Kubernetes on top of
CoreOS/fleet, on top of Docker Swarm or on Mesos.Docker
itself calls this Swarm Frontends and provides solutions to
deploy Kubernetes and Mesos/Marathon on top of Docker
Additionally, container orchestrators provide deploy-
ment unit-centric orchestrating. Deployment units can be
single containers or pods, which is a container with all
tightly coupled containers like associated storage containers
in case of Kubernetes. The orchestrator’s benefit is, that it
provides additional concepts to pure deploying of containers,
like high availability and elasticity features (see Figure 2
and [48] for more details on tools involved). These features
build the foundation to run elastic and distributed services
on top of such clusters (or better portable cloud runtime
(4) Clustered Storage. Most of the storage clusters are
not part of the container cluster but container clusters are
connected to scalable storage clusters in order to handle
stateful services. File storage could be realized as a service
on Layer 5. However, that might have some disadvantages.
Storage cluster solutions like Ceph,Gluster or Toru s need
very tight integration with the operating system (Layer
3). So, normally they do not provide their components in
a containerized form. Furthermore, Layer 4 orchestrator’s
already need mountable file systems on Layer 4 to provide
concepts like transferable volumes for containers. It would
violate layer design principles if a Layer 4 orchestrator
would use a Layer 5 service. It is more than likely that this
would end in a ”bootstraping paradox”. Both aspects led
to the decision to handle clustered storage as specialized
storage clusters on Layer 4. Typically the provided storage
is mountable by container hosts via POSIX standards like
NFS or alike. This approach makes it easy to integrate the
reference model with EA frameworks like TOGAF. TOGAF
defines a data architecture. The clustered storage component
is the realizing technological component for such a TOGAF
data architecture.
5.3. Service/application view point aka (P/S)aaS
A service centric view on cloud computing focuses non-
localizable services. A service can be composed of a mul-
titude of single deployment units (containers/pods)which
are deployed against and operated by a Layer 4 cluster.
To get the maximum benefit regarding safety and scala-
bility, these deployment units should be following cloud-
focused software design patterns (e.g. 12-factor app or
circuit breaker pattern). However, the cluster is responsible
to scale and balance all service related deployment units
to optimize service level quality. The presented model does
not make any assumptions about what kind of services are
operated. Most of the non-standardized services identified
in Table 2 are services on this Layer 5. Layer 5 services are
optimized for API-based collaboration (service to service
communication). Layer 6 applications focusing the end user
and are composed of Layer 5 services.
Layer 5: Services. In principal, arbitrary kind of services
can be operated. However, some main categories of services
and their accompanying frameworks can be categorized.
(1) Functional Services provide special functional ca-
pabilities as a service with API-based collaboration access.
There exist plenty of analytical (e.g. Hadoop/MapReduce),
prognostic (e.g. machine learning frameworks like Tensor-
Flow), messaging (e.g. RabbitMQ) and a lot of further
frameworks. Everything as a Service (or XaaS) is an often
heard term fitting very well with Layer 5. There exist single
standards like AMQP for messaging on this layer. However,
regarding all currently existing and provided public cloud
services we have to conclude that standardization on this
level seems very incomplete (see Table 2).
(2) All Purpose Services (like SpringCloud)areusedto
simplify application and service development by providing
proven cloud-focused development and scalable interaction
patterns. Most of the functional or all purposes services on
Layer 5 are not standardized at all (see Table 2).
(3) Storage Services often provide a REST-based API
to store data. So, they build a perfect fit for API-based
collaboration. Example frameworks are Swift (OpenStack),
S3 (AWS), RADOS (Ceph). These kind of services are of-
ten covered by the CDMI standard. And of course, these
services are aligned to data architectures requested by EA
frameworks like TOGAF.
Layer 6: Application. An application centric view on cloud
computing focuses the end user. Every Layer 5 service could
be a Layer 6 application as well, if the service is accessible
via a human machine interface (often this is realized via a
web interface or a specialized mobile application). It is often
the case, that Layer 5 services provide a Layer 6 human
machine interface as well (at least for some administration
purposes). Layer 6 applications are composed of Layer 5
services. Typical Layer 6 application examples are Google-
Docs,AWS WorkSpaces, or every other SaaS representative.
6. Evaluating the reference model
Table 2 shows the service portfolio of four major public
cloud service providers and their relationship to current
cloud standards. According to that, existing cloud standards
cover only specific cloud service categories and do not
show an integrated point of view. Instead of that, the pro-
posed reference model covers almost all of these identified
cloud services. Additionally, we discussed the suitability to
describe a concrete cloud application in a structured way
and checked conformance to the requirements for layered
architectures and with our made experience derived from
our action research activities.
The Social Collaboration Hub is a SaaS offering that
provides a complete intranet solution [49] based on well-
known open source products like Liferay and Open Xchange
(OX). On the physical layer (Layer 1) it builds on cheap
commodity server with two CPUs / 32 cores, 128 GB RAM,
2 SSDs and 5x 1 TB hard disks each. They are connected
with 10 GB ethernet. On the virtualization layer (Layer 2),
OpenStack with KVM is used. Ceph builds the storage clus-
ter and provides block storage to OpenStack Cinder using
all hard disks and the SSDs as a cache. OpenStack Neutron
provides an SDN to connect the VMs (Layer 2). Ubuntu
14.04 core LTS is used as operating system for the VMs
(Layer 3) with an installed Docker runtime environment
(Layer 3 Container Host). VMs are dedicated to customers
and not shared across them for better isolation and account-
ability. An Apache Mesos cluster is providing an abstraction
across all VMs (Layer 4 Scheduler). Labels are used to
assign Docker containers to the right VMs. Marathon is used
as an orchestrator and own extensions provide auto-scaling
(Layer 4 Orchestrator). Docker images are pulled from a
private registry. Stateful containers write to a data partition
mounted via Ceph volume plug-in, so that storage can be
easily migrated between hosts together with the container
(Layer 4 storage).Weav e is used as an overlay network to
enable communication between containers across multiple
host VMs (Layer 4 Overlay Network).
Service Category Google Azure AWS OpenStack
Compute Compute Engine Virtual Machines EC2 Nova C M M 2,3
Custom Machine Types Glance C M 2
App Engine Cloud Services Elastic Beanstalk 5
RemoteApp MobileHub + AppStream 5
Container Container Engine Container Service ECS Magnum ?
3, 4
Container Registry EC2 Container Registry ?
Storage Cloud Storage S3 Swift St 5
Storage (Disks) EBS Cinder St V St 2
Storage (Files) Elastic File System Manila St St 4
Nearline Backup Glacier 5
StorSimple 5
Storage Gateway 1
Networking Cloud Networking Virtual Network VPN Neutron N N 2
Express Route Direct Connect 1
Traffic Manager 4
Load Balancer ELB 4
Azure DNS Route 53 Designate 4
Media Services Elastic Transcoder 5
CDN Cloud Front 5
Cloud Endpoints Application Gateway API Gateway 5
Web Application Firewall 5
Database Cloud SQL SQL Database RDS Trove 5
SQL Data Warehouse Redshift 5
Datastore DocumentDB DynamoDB St 5
Big Table Storage (Tables) 5
Big Query 5
Data Flow Data Pipeline 5
Data Proc HDInsights EMR Sahara 5
Data Lake Store 5
Batch 5
Data Lab 5
Redis Cache ElastiCache 5
Database Migration Service -
Messaging PUB/SUB 5
Notification Hubs SNS 5
Notification Hubs SES 5
Event Hubs SQS + Lambda Zaqar 5
Storage (Queues) 5
Service Bus 5
Monitoring Cloud Monitoring Operational Insights Cloud Watch Ceilometer Mon 4
Cloud Logging CloudTrail 4
Management Cloud Deployment Manager Automation Cloud Formation Heat Sys Sys 4
OpsWork 4
Config + Service Catalog -
Azure Service Fabric 5
Site Recovery 5
API Management API Gateway 5
Mobile Engagement Mobile Analytics 5
Active Directory Directory Service 5
Multi Factor Authentication IAM Keystone 4
Certificate Manager 4
Key Vault CloudHSM Barbican 4
Security Center Trusted Advisor -
Inspector -
Further Survices Translate API 5
Prediction API Machine Learning Machine Learning 5
Data Lake Analytics Kinesis + QuickSight 5
Search Cloud Search 5
IoT Hub IoT 5
BizTalk Services 5
VS Team Services CodeCommit -
DevTests Labs CodePipeline&Deploy -
VS Application Insights 4
LumberJack 5
WorkSpaces, Mail, Docs 6
Sum of Services: 22 46 55 15 564121
OCCI Concepts: Compute = C, Network = N, Storage = St (used for CDMI as well)
CIMI Concepts: System = Sys (used for TOSCA as well), Machine = M (used for OVF as well), Volume = V, Network = N, Monitoring = Mon
ClouNS Layers: 1 = Physical, 2 = Virtual Node, 3 = Host, 4 = Cluster (Container/Storage), 5 = Service, 6 = Application
Currently not covered by ClouNS reference model.
Standard is in a working state, unclear whether aspect will be covered.
On Layer 5, a multitude of services is run. All data
about user accounts is stored in an OpenLDAP directory,
other data is stored in a Percona XtraDB cluster, which
is based on MySQL and Galera cluster technology. Mes-
saging is provided by Pos t x and Dovecot for emails and
an extension of Apache Shindig for social communication.
Shindig runs its own Neo4j database in embedded mode,
which is in line with the microservice architecture that
proposes freedom of choice for data stores. All these service
provide only an API, but no user interface on their own.
Real microservices with included GUI comprise CAS for
single sign-on, elasticsearch for enterprise search, camunda
for workflows and business process management as well
as Nuxeo for document storage. The application itself is
built on top of Liferay for social collaboration and OX
for groupware functionality (Layer 6).Nuxeo and Liferay
have own storage drivers for storing data in Amazon S3
compatible object stores, which are provided by Ceph. From
a categorization perspective, Liferay andOXaswellasthe
microservices do both have parts that belong to Layer 6
(GUI) and other parts that belong to Layer 5 (API).
Conformance with layered architectures and enter-
prise architecture methodologies. Due to page limitations
we can only provide some aspects of how we followed lay-
ered design principles. We started by a much more detailed
layered architecture of 9 layers and reduced them to six
layers in this proposal (Req 1). We reduced layers by shifting
boundaries to reduce interactions between layers (Req 2).
This layer reduction has been done intensively on Layer 4
but also on Layer 3. The reference model has layers for
separate functions and technologies (Req. 3, 4). We cover
IaaS, CaaS, PaaS and SaaS viewpoints for instance. Each
layer has boundaries with its upper and lower layer only
(Req. 5, 6 and 7). So concrete instances of a layer can be
replaced (e.g. Kubernetes could replace Mesos/Marathon as
a Layer 4 solution). Finally, we cross checked and adapted
these layers to be in accordance with EA frameworks like
7. Conclusion and outlook
We use the presented ClouNS reference model quite suc-
cessfully in our ongoing research to guide our technology
identification, classification, adoption, research and devel-
opment processes. Its main contribution for an enterprise
architecture context is its guidance. For vendor lock-in aware
enterprise architectures we advocate to operate cloud-native
applications on something that can be called a portable
cloud runtime environment (Layer 4 according to our pro-
posed reference model) to avoid vendor lock-in vulnerabili-
ties coming along with higher cloud service layers. From the
authors’ point of view, the importance of these platforms for
cloud computing is comparable to the positive impact of the
Java Virtual Machine specification on platform-independent
application development in the 1995’s.
Of course the reference model can be detailed in some
aspects. Especially Layer 5 services could be categorized
more precisely to provide more guidance for enterprise
architecture methodologies. This could be done by applying
cloud service taxonomy systems [50]. For each layer and
service category more detailed feature requirements and
standardized data transferability requirements were desir-
able. This could be done by integrating requirement analysis
outcomes presented for instance in [48]. And finally, more
detailed upward and downward standardization requirements
for each layer were helpful to support vendor lock-in avoid-
ance more systematically in enterprise architecture modeling
[1]. All this is up for ongoing research. However, the ClouNs
reference model in its current state can already help to make
technologies, research approaches and standardization for
cloud-native application development and enterprise archi-
tecture modeling more comparable, more codifyable and
finally more integrated.
Acknowledgments. We would like to thank Dr. Adersberger
from QAWARE GmbH. He inspired us with his thoughts about
his MEKUNS approach (Mesos, Kubernetes, Cloud-native Stack).
This research is funded by German Federal Ministry of Education
and Research (Project Cloud TRANSIT, 03FH021PX4; Project
SCHub, 03FH025PX4).
[1] C. Pahl, L. Zhang, and F. Fowley, “A Look at Cloud Architecture
Interoperability through Standards,” in 4th. Int. Conf. on Cloud Com-
puting, GRIDs, and Virtualization (CLOUD COMPUTING 2013),
vol. 1, no. 1, 2013, pp. 7–12.
[2] M. Hogan, L. Fang, A. Sokol, and J. Tong, “Cloud Infrastructure
Management Interface (CIMI) Model and RESTful HTTP-based
Protocol, Version 2.0.0c,” 2015. [Online]. Available: http://www.nist.
gov/customcf/get pdf.cfm?pub id=909024
[3] R. Nyren, A. Edmonds, A. Papaspyrou, and T. Metsch, “Open Cloud
Computing Interface (OCCI) - Core, Version 1.1,” 2011. [Online].
[4] T. Metsch and A. Edmonds, “Open Cloud Computing Interface
(OCCI) - Infrastructure, Version 1.1,” 2011. [Online]. Available:
[5] B. Satzger, W. Hummer, C. Inzinger, P. Leitner, and S. Dustdar,
“Winds of Change: From Vendor Lock-In to the Meta Cloud,” Internet
Computing, IEEE, vol. 17, no. 1, pp. 69–73, Jan 2013.
[6] C. Fehling, F. Leymann, R. Retter, W. Schupeck, and P. Arbitter,
Cloud Computing Patterns: Fundamentals to Design, Build, and Man-
age Cloud Applications. Springer Publishing Company, Incorporated,
[7] M. Stine, Migrating to Cloud-Native Application Architectures.
O’Reilly, 2015.
[8] A. Balalaie, A. Heydarnoori, and P. Jamshidi, “Migrating to Cloud-
Native Architectures Using Microservices: An Experience Report,
in 1st Int. Workshop on Cloud Adoption and Migration (CloudWay),
Taormina, Italy, 2015.
[9] S. Newman, Building Microservices. O’Reilly Media, Incorporated,
[10] D. Namiot and M. Sneps-Sneppe, “On micro-services architecture,”
Int. Journal of Open Information Technologies, vol. 2, no. 9, 2014.
[11] Adam Wiggins, “The Twelve-Factor App,” 2014, last access
2016-02-14. [Online]. Available:
[12] Martin Fowler, “Circuit Breaker,” 2014, last access 2016-05-27.
[Online]. Available:
[13] The Linux Information Project, “Vendor Lock-in Definition,” 2006,
last access 2016-02-14. [Online]. Available:
vendor lockin.html
[14] W. B. Arthur, “Competing Technologies, Increasing Returns, and
Lock-In by Historical Events,” The Economic Journal, vol. 99, no.
394, pp. 116–131, 1989.
[15] B. Di Martino, G. Cretella, and A. Esposito, “Classification and Po-
sitioning of Cloud Definitions and Use Case Scenarios for Portability
and Interoperability,” in 3rd Int. Conf. on Future Internet of Things
and Cloud (FiCloud 2015). IEEE, 2015, pp. 538–544.
[16] N. Kratzke and P.-C. Quint, “About Automatic Benchmarking of IaaS
Cloud Service Providers for a World of Container Clusters,” Journal
of Cloud Computing Research, vol. 1, no. 1, pp. 16–34, 2015.
[17] N. Kratzke, “Lightweight Virtualization Cluster - How to overcome
Cloud Vendor Lock-In,” Journal of Computer and Communication
(JCC), vol. 2, no. 12, Oct. 2014.
[18] J. Opara-Martins, R. Sahandi, and F. Tian, “Critical review of vendor
lock-in and its impact on adoption of cloud computing,” in Int. Conf.
on Information Society (i-Society 2014), Nov 2014, pp. 92–97.
[19] J. Durand, M. Andreou, D. Davis, and G. Pilz, “NIST Cloud Com-
puting Standards Roadmap,” 2011. [Online]. Available: https://www. 2.0.0c.pdf
[20] System Virtualization, Partitioning, and Clustering Working
Group, “Open Virtualization Format Specification, Version 2.1.0,”
2015. [Online]. Available:
standards/documents/DSP0243 2.1.1.pdf
[21] SNIA, “Cloud Data Management Interface (CDMI), Version
1.1,” 2015. [Online]. Available:
files/CDMI Spec v1.1.1.pdf
[22] Intercloud WG (ICWG) Working Group, “Standard for Intercloud
Interoperability and Federation (SIIF).” [Online]. Available: https:
[23] ——, “Guide for Cloud Portability and Interoperability Profiles
(CPIP).” [Online]. Available:
[24] B. Di Martino, G. Cretella, and A. Esposito, “Cross-platform cloud
APIs,” in Cloud Portability and Interoperability. Springer, 2015, pp.
[25] G. Juve and E. Deelman, “Automating application deployment in in-
frastructure clouds,” in 3rd Int. Conf. on Cloud Computing Technology
and Science (CLOUDCOM 2011). Washington, DC, USA: IEEE
Computer Society, 2011, pp. 658–665.
[26] C. de Alfonso, M. Caballer, F. Alvarruiz, G. Molto, and V. Hernandez,
“Infrastructure Deployment Over the Cloud,” in 3rd Int. Conf. on
Cloud Computing Technology and Science (CLOUDCOM 2011),Nov
2011, pp. 517–521.
[27] A. Lenk, C. Danschel, M. Klems, D. Bermbach, and T. Kurze,
“Requirements for an IaaS deployment language in federated Clouds,”
in Int. Conf. on Service-Oriented Computing and Applications (SOCA
2011), Dec 2011, pp. 1–4.
[28] S. Murphy, S. Gallant, C. Gaughan, and M. Diego, “U.S. Army
Modeling and Simulation Executable Architecture Deployment Cloud
Virtualization Strategy,” in 12th Int. Symp. on Cluster, Cloud and Grid
Computing (CCGrid), May 2012, pp. 880–885.
[29] OASIS, “Topology and Orchestration Specification for Cloud
Applications (TOSCA), Version 1.0,” 2013. [Online]. Available: os.pdf
[30] D.-H. Le, H.-L. Truong, G. Copil, S. Nastic, and S. Dustdar, “SALSA:
A Framework for Dynamic Configuration of Cloud Services,” in 6th
Int. Conf. on Cloud Computing Technology and Science (CloudCom
2014), Dec 2014, pp. 146–153.
[31] R. Zabolotnyi, P. Leitner, S. Schulte, and S. Dustdar, “SPEEDL - A
Declarative Event-Based Language for Cloud Scaling Definition,” in
IEEE World Congress on Services (SERVICES 2015), 2015.
[32] G. Copil, D. Moldovan, H. L. Truong, and S. Dustdar, “SYBL: An Ex-
tensible Language for Controlling Elasticity in Cloud Applications,”
in 13th IEEE/ACM Int. Symp. on Cluster, Cloud and Grid Computing
(CCGrid 2013). IEEE Computer Society, 2013, pp. 112–119.
[33] ISO/OSI, “Open Systems Interconnection - Basic Ref-
erence Model: The Basic Model,” 1994. [Online].
s020269 ISO IEC 7498-1 1994(E).zip
[34] K. Winter, S. Buckl, F. Matthes, and C. M. Schweda, “Investigating
the state-of-the-art in enterprise architecture management methods in
literature and practice.” Mediterranean Conference on Information
Systems (MCIS 2010), vol. 90, 2010.
[35] J. Zachman, “John Zachman’s Concise Definition of the Zachman
Framework,” 2008. [Online]. Available:
[36] P. M. Mell and T. Grance, “The NIST Definition of Cloud Com-
puting,” National Institute of Standards & Technology, Gaithersburg,
MD, United States, Tech. Rep., 2011.
[37] R. B. Bohn, J. Messina, F. Liu, J. Tong, and J. Mao, “Nist cloud
computing reference architecture,” in World Congr. on Services (SER-
VICES 2011). Washington, DC, USA: IEEE Computer Society, 2011,
pp. 594–596.
[38] IEEE and OpenGroup, “The Open Group Base Specifications Issue 7,
IEEE Std 1003.1, 2013 Edition (POSIX Standard),” 2013. [Online].
[39] R. Peinl and F. Holzschuher, “The Docker Ecosystem Needs Consol-
idation,” in 5th Int. Conf. on Cloud Computing and Services Science
(CLOSER 2015), 2015, pp. 535–542.
[40] OCI, “Open Container Initiative,” 2015, last access 2016-02-04.
[Online]. Available:
[41] Docker Inc., “Containers as a Service (CaaS) as your new platform
for application development and operations,” 2016, latest access
2016-02-05. [Online]. Available:
[42] B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A. D. Joseph,
R. H. Katz, S. Shenker, and I. Stoica, “Mesos: A Platform for Fine-
Grained Resource Sharing in the Data Center.” in 8th USENIX Conf.
on Networked systems design and implementation (NSDI’11), vol. 11,
[43] A. Verma, L. Pedrosa, M. R. Korupolu, D. Oppenheimer, E. Tune, and
J. Wilkes, “Large-scale cluster management at Google with Borg,” in
10th. Europ. Conf. on Computer Systems (EuroSys ’15), Bordeaux,
France, 2015.
[44] P.-C. Quint and N. Kratzke, “Overcome Vendor Lock-In by Integrat-
ing Already Available Container Technologies - Towards Transfer-
ability in Cloud Computing for SMEs,” in 7th. Int. Conf. on Cloud
Computing, GRIDS and Virtualization (CLOUD COMPUTING 2016),
[45] Weave, “Weave Net,” 2016, last access 2016-02-05. [Online].
[46] Calico, “Calico - A Pure Layer 3 Approach to Virtual Networking
for Highly Scalable Data Centers,” 2016, last access 2016-02-05.
[Online]. Available:
[47] CoreOS, “flannel - a virtual network that gives a subnet to each
host for use with container runtimes,” 2016, last access 2016-02-05.
[Online]. Available:
[48] R. Peinl, F. Holzschuher, and F. Pfizer, “Docker cluster management
- survey results and future,Journal of Grid Computing, 2016, to be
[49] R. Peinl, “Supporting Knowledge Management Instruments with
Composable Micro-Services,” in Wissensgemeinschaften - ProWM
2015, Dresden, Juni 2015, 2015.
[50] C. N. H¨
ofer and G. Karagiannis, “Cloud computing services: taxon-
omy and comparison,” Journal of Internet Services and Applications,
vol. 2, no. 2, pp. 81–94, 2011.
... According to an analysis performed in 2016 [1], the percentage of these commodity service categories that are considered in standards like CIMI, OCCI, CDMI, OVF, OCI, TOSCA is even decreasing over the years. This decrease has mainly to do with the fact that new cloud service categories are released faster than standardization authorities can standardize existing service categories. ...
... It became clear that cloud-native applications share many common characteristics that can be exploited for transferability. As such, we compiled a reference model that plenty of cloud-native applications have in common [1]. As Fig. 2 shows, two basic operation modes of cloud-native applications are reasonable. ...
... A reference architecture that many cloud-native applications have in common[1]. ...
Full-text available
Kubernetes (k8s) is a kind of cluster operating system for cloud-native workloads that has become a de-facto standard for container orchestration. Provided by more than one hundred vendors, it has the potential to protect the customer from vendor lock-in. However, the open-source k8s distribution consists of many optional and alternative features that must be explicitly activated and may depend on pre-configured system components. As a result, incompatibilities still may ensue among Kubernetes vendors. Mostly managed k8s services typically restrict the customizability of Kubernetes. This paper firstly compares the most relevant k8s vendors and, secondly, analyses the potential of Kubernetes to detect and configure compatible support for required features across vendors in a uniform manner. Our comparison is performed based on documented features, by testing, and by inspection of the configuration state of running clusters. Our analysis focuses on the potential of the end-to-end testing suite of Kubernetes to detect support for a desired feature in any Kubernetes vendor and the possibility of reconfiguring the studied vendors with missing features in a uniform manner. Our findings are threefold: First, incompatibilities arise between default cluster configurations of the studied vendors for approximately 18% of documented features. Second, matching end-to-end tests exist only for around 64% of features and for 17% of features these matching tests are not well developed for all vendors. Third, almost all feature incompatibilities can be resolved using a vendor-agnostic API. These insights are beneficial to avoid feature incompatibilities already in cloud-native application engineering processes. Moreover, the end-to-end testing suite can be extended in currently unlighted areas to provide better feature coverage.
... In past and current industrial action research [4,6,[8][9][10][11][12][13][14], I came across various cloud-114 native applications and corresponding engineering methodologies like the 12-factor app 115 (see 4.1) and learned that the discussion around observability is increasingly moving 116 beyond these three stovepipes and taking a more nuanced and integrated view. There is a 117 growing awareness of integrating and unifying these three pillars, and more emphasis is 118 being placed on analytics. ...
Full-text available
Background: Cloud-native software systems often have a much more decentralized structure and many independently deployable and (horizontally) scalable components, making it more complicated to create a shared and consolidated picture of the overall decentralized system state. Today, observability is often understood as a triad of collecting and processing metrics, distributed tracing data, and logging. The result is often a complex observability system composed of three stovepipes whose data is difficult to correlate. Objective: This study analyzes whether these three historically emerged observability stovepipes of logs, metrics and distributed traces could be handled more integrated and with a more straightforward instrumentation approach. Method: This study applied an action research methodology used mainly in industry-academia collaboration and common in software engineering. The research design utilized iterative action research cycles, including one long-term use case. Results: This study presents a unified logging library for Python and a unified logging architecture that uses the structured logging approach. The evaluation shows that several thousand events per minute are easily processable. Conclusion: The results indicate that a unification of the current observability triad is possible without the necessity to develop utterly new toolchains.
... The requirements can change dynamically at runtime. -Reacting to events concerning resource allocation -the environment has to discover changes in requirements for resources and changes in the level of resource availability on each layer of the Cloud-native stack [44]. Hence, it should be possible to discover cases of inefficient resource allocation resulting from their partial use or lack of required resources. ...
Full-text available
The policy-based management paradigm in a flexible manner governs the system behavior. For Cloud-native applications, additionally, it simplifies the compliance with CI/CD objectives. Hence, the velocity of changes in requirements made at runtime does not influence the system implementation. Continuously the adjustments are integrated into the system on the fly. This paper evaluates the rule-based approach to representing policies in the context of Cloud-native applications. Deploying applications in orchestrated environments is one of the main principles of Cloud-native. Our approach represents the extension of the management characteristics that are available in current implementations of the orchestrators. The presented study also shows a general methodology for experimental evaluation of complex Cloud-native environments. We propose two categories of experiments. Both evaluate the rule-based approach. The first category evaluates the impacts of dynamic adjustment of resources in the context of the Cloud-native execution environment. The second category assesses the influence of the rule engine approach on the autonomic management process. Given the wide range of available experiments, we additionally assume that evaluation is performed from the point of view of the execution environment's resources. This approach tightly embraces the capabilities of the proposed solution realized by the AMoCNA system and demonstrates its usability.
... However, these are not linked and cannot be evaluated as a whole. The stated problem is not addressed in any known publications -although there is related research in the scope of specific concepts, and there also similar concepts which concern old technologies [1,4,20,33,45,49]. ...
Full-text available
In order to meet the rapidly changing requirements of the Cloud-native dynamic execution environment, without human support and without the need to continually improve one's skills, autonomic features need to be added. Embracing automation at every layer of performance management enables us to reduce costs while improving outcomes. The main contribution of this paper is the definition of autonomic management requirements of Cloud-native applications. We propose that the automation is achieved via high-level policies. In turn autonomy features are accomplished via the rule engine support. First, the paper presents the engineering perspective of building a framework for Autonomic Management of Cloud-Native Applications, namely AMoCNA, in accordance with Model Driven Architecture (MDA) concepts. AMoCNA has many desirable features whose main goal is to reduce the complexity of managing Cloud-native applications. The presented models are, in fact, meta-models, being technology agnostic. Secondly, the paper demonstrates one possibility of implementing the aforementioned design procedures. The presented AMoCNA implementation is also evaluated to identify the potential overhead introduced by the framework.grid
... Kratzke and Peinl [36] presented the anatomy of the cloud-native stack which is a good summary of components of cloud-native developments but it does not address the full set of enterprise stakeholders. A reference architecture for designing microservices is given by Yu et al. [59]. ...
Full-text available
Widespread adoption of agile project management, independent delivery with microservices, and automated deployment with DevOps has tremendously speedup the systems development. The real game-changer is continuous development (CD), independent deployment, and continuous integration (CI). Organizations can do multiple releases a day, shortening the test, release, and deployment cycles from weeks to minutes. Maturity of container technologies like Docker and container orchestration platforms like Kubernetes has promoted microservices architecture, especially in the cloud-native developments. Various tools are available for setting up CD and CI pipelines. Organizations can quickly accumulate hundreds of such microservices accessible via application programming interfaces (APIs). The primary purpose of these modern methodologies is agility, speed, and reusability. While DevOps offers speed and time to market, agility and reusability may not be guaranteed unless microservices and API's are linked to enterprise-wide stakeholder needs. The link between business needs and microservices/APIs is not well captured nor adequately defined. In this publication, we describe a structured method to create a logical link among APIs and microservices-based agile developments and enterprise stakeholder viewpoints. This method enables capturing and documenting enterprise-wide stakeholders' needs, whether these are business owners, planners (product owners, architects), designers (developers, DevOps engineers), or the partners and subscribers of an enterprise.
... It favors small, stateless, siloed components with clean interfaces to maximize horizontal scalability and concurrent development while minimizing downtimes. The most commonly published works about cloud-native transformation of legacy workloads cover stateless applications [15][16][17][18][19][20][21][22][23]. Facebook developed Turbine, which is a cloud native platform for managing their streaming applications on their Tupperware container platform [24]. ...
We present the architecture of a cloud native version of IBM Streams, with Kubernetes as our target platform. Streams is a general purpose streaming system with its own platform for managing applications and the compute clusters that execute those applications. Cloud native Streams replaces that platform with Kubernetes. By using Kubernetes as its platform, Streams is able to offload job management, life cycle tracking, address translation, fault tolerance and scheduling. This offloading is possible because we define custom resources that natively integrate into Kubernetes, allowing Streams to use Kubernetes' eventing system as its own. We use four design patterns to implement our system: controllers, conductors, coordinators and causal chains. Composing controllers, conductors and coordinators allows us to build deterministic state machines out of an asynchronous distributed system. The resulting implementation eliminates 75% of the original platform code. Our experimental results show that the performance of Kubernetes is an adequate replacement in most cases, but it has problems with oversubscription, networking latency, garbage collection and pod recovery.
... By studying published research (i. e., Fehling et al. 2014;Kratzke and Peinl 2016;Leymann et al. 2017;Stine 2015; just to mention some) and existing trends in engineering such applications, they defined the term "cloud-native application" as a distributed, elastic, and horizontally scalable system composed of services and operated on self-service platforms, while the services itself are designed as self-contained deployment units according to cloud design patterns. ...
The adoption of cloud computing combined with DevOps enables companies to react to new market requirements more rapidly and fosters the use of automation technologies. This influences the way software solutions are built, which is why the concept of cloud-native applications has emerged over the last few years to build highly scalable applications, and to automatically deploy and run them in modern cloud environments. However, there is currently no reference work clearly stating the features that a deployment technology must offer to support the deployment of arbitrary cloud-native applications. In this paper, we derive three essential features for deployment technologies based on the current cloud-native research and characteristics discussed therein. The presented features can be used to compare and categorize existing deployment technologies, and they are intended to constitute a first step towards a comprehensive framework to assess deployment technologies.
Conference Paper
Full-text available
Cloud Computing has crossed the chasm and it is now for the adopters to avoid being laggards. They must choose it before losing market share to their competitors. Across all the Industry verticals, be it Automotive, Aerospace, Telecom, Life Sciences, Manufacturing or Retail; Cloud has disrupted the traditional business models. IT teams of these verticals are under tremendous pressure to move their solutions to cloud. What makes it complicated is the multiple cloud offerings available to make this happen and every choice with its own trade-offs. Another dimension that makes Infra and IT Architects nervous about cloud journey is the outcome expected from it. Not only that business should run as usual post cloud journey, operating expenditures must come down, returns on investments must be visible and user experience must improve. It makes the decision to design it right the first time paramount. This paper attempts to introduce Cloud computing and its impact, highlight the need to embrace it and an approach for cost-sensitive adopters in implementing Cloud Native Applications.
In recent years, the investigations on Cyber-Physical Systems~(CPS) have become increasingly popular in both academia and industry. A primary obstruction against the booming deployment of CPS applications lies in how to process and manage large amounts of generated data for decision making. To tackle this predicament, researchers advocate the idea of coupling edge computing or edge-cloud computing into the design of CPS. However, this coupling process raises a diversity of challenges to the Quality-of-Services~(QoS) of CPS applications. In this paper, we present a survey on edge computing or edge-cloud computing assisted CPS designs from the QoS optimization perspective. We first discuss critical challenges in service latency, energy consumption, security, privacy, and reliability during the integration of CPS with edge computing or edge-cloud computing. Afterwards, we give an overview on the state-of-the-art works tackling different challenges for QoS optimization, and present a systematic classification during outlining literatures for highlighting their similarities and differences. We finally summarize the experiences learned from surveyed works and envision future research directions on edge computing or edge-cloud computing assisted CPS optimization
Full-text available
Docker provides a good basis to run composite applications in the cloud, especially if those are not cloud-aware, or cloud-native. However, Docker concentrates on managing containers on one host, but SaaS provi¬ders need a container management solution for multiple hosts. Therefore, a number of tools emerged that claim to solve the problem. This paper classifies the solutions, maps them to requirements from a case study and identifies gaps and integration requirements. We close some of these gaps with our own integration components and tool enhancements, resulting in the currently most complete management suite.
Conference Paper
Full-text available
Container clusters have an inherent complexity. A distributed container application in the cloud can be complex at planning, installation and configuration, maintenance and search for failures. Small and medium enterprises (SMEs) are mostly limited by their personnel and financial restrictions. Using advanced cloud technologies like a container cluster often requires high personnel expenses or the use of an external system builder. In addition to economical, security-and governance issues there is also the concern of technical vendor lock-ins. This paper introduces C 4 S, an open source system for SMEs to deploy and operate their container application with features like elasticity, auto-scaling and load balancing. The system also supports transferability features for migrating container between different Infrastructure as a Service (IaaS) platforms. This paper presents a solution for SMEs to use the benefits of cloud computing without the disadvantages of vendor lock-in.
Conference Paper
Full-text available
Migration to the cloud has been a popular topic in industry and academia in recent years. Despite many benefits that the cloud presents, such as high availability and scalability, most of the on-premise application architectures are not ready to fully exploit the benefits of this environment, and adapting them to this environment is a non-trivial task. Microservices have appeared recently as novel architectural styles that are native to the cloud. These cloud-native architectures can facilitate migrating on-premise architectures to fully benefit from the cloud environments because non-functional attributes, like scalability, are inherent in this style. The existing approaches on cloud migration does not mostly consider cloud-native architectures as their first-class citizens. As a result, the final product may not meet its primary drivers for migration. In this paper, we intend to report our experience and lessons learned in an ongoing project on migrating a monolithic on-premise software architecture to microservices. We concluded that microservices is not a one-fit-all solution as it introduces new complexities to the system, and many factors, such as distribution complexities, should be considered before adopting this style. However, if adopted in a context that needs high flexibility in terms of scalability and availability, it can deliver its promised benefits.
This chapter illustrates the main cross-platform cloud application programming interfaces and how they can solve interoperability and portability issues by bringing uniformity and standardization to cloud. This chapter provides an overview of initiatives that provide cross-platform-based cloud APIs such as DeltaCloud, SimpleCloud, JCloud, libcloud, and also research projects whose aim is to provide multicloud APIs (such as mOSAIC). Such APIs are positioned with respect to the use case scenarios and features defined in Chap. 1, and tested by analyzing their application to the case study illustrated in Chap. 1.
Google's Borg system is a cluster manager that runs hundreds of thousands of jobs, from many thousands of different applications, across a number of clusters each with up to tens of thousands of machines. It achieves high utilization by combining admission control, efficient task-packing, over-commitment, and machine sharing with process-level performance isolation. It supports high-availability applications with runtime features that minimize fault-recovery time, and scheduling policies that reduce the probability of correlated failures. Borg simplifies life for its users by offering a declarative job specification language, name service integration, real-time job monitoring, and tools to analyze and simulate system behavior. We present a summary of the Borg system architecture and features, important design decisions, a quantitative analysis of some of its policy decisions, and a qualitative examination of lessons learned from a decade of operational experience with it.
Conference Paper
Cloud Computing has rapidly evolved and spread in the past few years, with always new services and functionalities being offered by providers in order to gain larger market sectors. This has caused in many cases a lot of distress and confusion to customers who have been often subjected to the “vendor lock- in”phenomenon, because of interoperability and portability issues often arising among different Cloud providers. In this paper we provide a brief introduction to the basic definitions of Cloud Computing, portability and interoperability and we also describe a set of established use cases. All these notions are mapped to a multi-dimensional space, which is used to classify both definitions and use cases. The focus here is represented by portability and interoperability features.