AUTOGENIC: Automated Generation of Self-conﬁguring Microservices

Stefan Kehrer and Wolfgang Blochinger

Department of Computer Science, Reutlingen University, Alteburgstr. 150, 72762 Reutlingen, Germany

Keywords:

Microservices, DevOps, Container Virtualization, Conﬁguration, Service Registry, TOSCA, Docker, Consul.

Abstract:

The state of the art proposes the microservices architectural style to build applications. Additionally, container

virtualization and container management systems evolved into the perfect ﬁt for developing, deploying, and

operating microservices in line with the DevOps paradigm. Container virtualization facilitates deployment

by ensuring independence from the runtime environment. However, microservices store their conﬁguration in

the environment. Therefore, software developers have to wire their microservice implementation with techno-

logies provided by the target runtime environment such as conﬁguration stores and service registries. These

technological dependencies counteract the portability beneﬁt of using container virtualization. In this paper,

we present AUTOGENIC - a model-based approach to assist software developers in building microservices

as self-conﬁguring containers without being bound to operational technologies. We provide developers with

a simple conﬁguration model to specify conﬁguration operations of containers and automatically generate a

self-conﬁguring microservice tailored for the targeted runtime environment. Our approach is supported by a

method, which describes the steps to automate the generation of self-conﬁguring microservices. Additionally,

we present and evaluate a prototype, which leverages the emerging TOSCA standard.

1 INTRODUCTION

Today’s business environment requires fast software

release cycles. To address this issue, continuous deli-

very and DevOps aim at bridging the gap between de-

velopment and operations by employing automation

and self-service tools. Microservices are an evolving

architectural style for building and releasing software

in line with the DevOps paradigm (Balalaie et al.,

2016; Pahl and Jamshidi, 2016). Microservices are

autonomous and independently deployable (Newman,

2015).

Unfortunately, the autonomous nature of micro-

services challenges their development: More and

more operational aspects are transferred into the re-

sponsibility of software developers - or how Amazon

calls it: “you build it, you run it” (O’Hanlon, 2006).

This is also enabled by technological advances such

as container virtualization (Kratzke and Quint, 2017;

Pahl and Jamshidi, 2016): Microservices are com-

monly built as a set of containers, which provide a

portable means to deploy microservices on state of the

art container management systems such as Marathon

https://mesosphere.github.io/marathon.

on Apache Mesos

, Kubernetes

, or Docker Swarm

In line with this trend, software developers have

to implement their microservices including operatio-

nal behavior. Every container that is part of the mi-

croservice has to be conﬁgured with speciﬁc runtime

parameters as well as endpoint information to inte-

ract with other containers. This conﬁguration of con-

tainers might be applied during the deployment of a

microservice. However, in a dynamic environment

such as the cloud, dynamic updates of runtime pa-

rameters might be required. Furthermore, endpoint

information will likely change during runtime, e.g., if

a container has to be restarted. Thus, microservices

store their conﬁguration in the environment

. This

means that conﬁguration stores are used to store re-

quired runtime parameters and service registries are

used to ﬁnd other containers. Following this appro-

ach, software developers have to wire their microser-

vice implementation with technologies provided by

the runtime environment. Besides adding more com-

plexity, this leads to heterogeneous implementations

of conﬁguration management. Moreover, technologi-

https://mesos.apache.org.

https://kubernetes.io.

https://github.com/docker/swarm.

https://12factor.net/conﬁg.

Kehrer, S. and Blochinger, W.

AUTOGENIC: Automated Generation of Self-conﬁguring Microservices.

DOI: 10.5220/0006659800350046

In Proceedings of the 8th International Conference on Cloud Computing and Services Science (CLOSER 2018), pages 35-46

ISBN: 978-989-758-295-0

cal dependencies on conﬁguration stores and service

registries provided by the runtime environment decre-

ase the portability beneﬁt inherent to containers.

To address the aforementioned challenges, we

present a novel approach called AUTOmated GENe-

ration of self-conﬁguring mICroservices (AUTOGE-

NIC). Our model-based approach enables software

developers to specify the conﬁguration operations of

containers with a conﬁguration model. Based on this

model, we transform a supplied microservice into

a self-conﬁguring microservice by automatically ad-

ding runtime behavior to its containers on a techni-

cal level. As a result, conﬁguration is managed by

each container and thus accomplished in a decentrali-

zed manner. This transformation is provided as a ser-

vice to developers and thus decouples environment-

speciﬁc technologies from application development.

Our approach streamlines the cooperation of deve-

lopers and operations personnel by providing an ab-

straction layer between both groups, which basically

implements the separation of concerns principle in the

DevOps context. In particular, we present the follo-

wing contributions:

• We introduce the AUTOGENIC approach to assist

software developers in creating self-conﬁguring

microservices.

• We provide the AUTOGENIC method, which des-

cribes the steps of generating self-conﬁguring mi-

croservices on a conceptual level.

• We present an implemented prototype, which au-

tomates the AUTOGENIC method based on the

TOSCA standard and state of the art technologies.

The paper is structured as follows. In Section 2,

we describe microservices in general and motivate our

work. Section 3 gives an overview of the general con-

cepts of the AUTOGENIC approach. In Section 4,

we discuss the AUTOGENIC method, which descri-

bes the required steps to automate the generation of

self-conﬁguring microservices. Further, we present

an implemented prototype in Section 5 and evaluate

this prototype in Section 6. In Section 7, we review

related work. Finally, Section 8 concludes this paper

and describes future work.

2 STATE OF THE ART AND

MOTIVATION

In this section, we describe the state of the art and pre-

sent an exemplary microservice to motivate our work.

2.1 Microservices

A microservice is built around a business capabi-

lity and implements the user interface, storage, and

any external collaborations required (Lewis and Fow-

ler, 2014). Thus, each microservice is a broad-stack

implementation of software for a speciﬁc business

capability (Lewis and Fowler, 2014). Microservi-

ces combine concepts from distributed systems and

service-oriented architecture leading to several bene-

ﬁts (Newman, 2015). For instance, microservices can

be implemented with different technologies enabling

a best-of-breed approach. Thus, new technologies

can be adopted and old technologies can be replaced

much faster. Composing a system out of many small

services also provides beneﬁts for deployment and

management: It allows to deploy and scale every mi-

croservice independently (Leymann et al., 2017). Ty-

pically, software containers are used to package and

deploy microservice components (Pahl et al., 2017).

A topology model or template, which describes the

containers a microservice is composed of and their

relationships, enables automated deployment (Kehrer

and Blochinger, 2017).

However, the beneﬁts of microservices come with

the cost of operational complexity (Fowler, 2017).

The autonomous nature inherent to microservices re-

quires application developers to take responsibility

for operational aspects such as dynamic conﬁguration

(Kookarinrat and Temtanapat, 2016). To this end, the

Twelve-Factor App

principles propose to store these

information in the runtime environment. Technolo-

gies such as conﬁguration stores and service regis-

tries are used to store conﬁguration values and ena-

ble dynamic bindings among containers. Employing

technologies like Consul

, Etcd

, or Zookeeper

is a

common practice for developing microservices (Tof-

fetti et al., 2017). They provide a scalable medium to

store conﬁguration information.

2.2 Motivation

In this section, we introduce a microservice, which is

used as motivating example for our work. The topo-

logy of this microservice is composed of four contai-

ners interacting with each other (cf. Figure 1): The

wordpress container provides an Apache HTTP server

running a WordPress installation. The mysql contai-

ner runs a MySQL database. To answer user requests,

https://12factor.net.

https://www.consul.io.

https://github.com/coreos/etcd.

https://zookeeper.apache.org.

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

Configuration

Store

A PI

Service

Registry

A PI

ConnectsTo

wordpress mysql

memcached

backup

ConnectsTo

Figure 1: Exemplary microservice storing its conﬁguration

in the runtime environment.

the wordpress container connects to the mysql contai-

ner and retrieves data stored in the relational database.

Frequently requested results are cached in the mem-

cached container, which runs a Memcached

instal-

lation. Memcached is an in-memory object caching

system. The memcached container is queried by the

wordpress container before sending a read request to

the mysql container. Additionally, a separate backup

container periodically stores backups of the MySQL

database by connecting to the corresponding contai-

ner.

For conﬁguration purposes, every container of the

formerly described microservice requires its runtime

parameters and endpoint information to interact with

other containers in the topology. To access their run-

time parameters, the containers connect to a conﬁgu-

ration store provided by the runtime environment. Si-

milarly, every container connects to a service registry

to access endpoint information of other containers (cf.

Figure 1). Whenever a runtime parameter or endpoint

information changes in the environment, a container

itself is responsible for reacting to this change. This

results in software developers having to wire their im-

plementations with operational technologies provided

by the runtime environment.

We identiﬁed several problems with this appro-

ach: (1) APIs of the conﬁguration store and the ser-

vice registry have to be used by software developers.

Every time the operations personnel decides to choose

another technology, software developers have to be

instructed and existing microservice implementations

have to be modiﬁed. (2) Storing endpoint information

of containers belonging to a microservice in a cen-

https://memcached.org.

tral service registry may lead to conﬂicts with other

deployments and breaks the microservice paradigm,

e.g., if another service requester receives the endpoint

information of our MySQL database. This informa-

tion should be kept private and not exposed to other

microservices (O’Hanlon, 2006; Lewis and Fowler,

2014). (3) Moreover, portability is limited, i.e., mi-

croservices cannot be deployed on a runtime environ-

ment that does not provide the required technologies.

In general, software developers are confronted

with a lot of often changing technologies to enable

dynamic conﬁguration. Technological dependencies

on speciﬁc conﬁguration stores or service registries

counteract the portability beneﬁt of using container

virtualization. New solutions are required, which

assist software developers in implementing dynamic

conﬁguration for their microservices.

3 AUTOMATED GENERATION

OF SELF-CONFIGURING

MICROSERVICES

We propose AUTOmated GENeration of self-

conﬁguring mICroservices (AUTOGENIC) to assist

software developers in building dynamically conﬁgu-

ring microservices. We aim at providing a simple me-

ans for software developers to take responsibility for

operational aspects of their microservice in line with

the “you build it, you run it” principle. We identi-

ﬁed two fundamental design guidelines for such an

approach: (1) Software developers have to be able to

control the conﬁguration of containers belonging to

a microservice. (2) Technological details should be

hidden from software developers to enable portability

and operational ﬂexibility with respect to the runtime

environment and tool support.

Basically, AUTOGENIC is a model-based appro-

ach to decouple the development of microservices

from environment-speciﬁc technologies provided by

operations personnel. Software developers simply

specify conﬁguration operations of their microservice

in a conﬁguration model, i.e., without considering

the speciﬁc technologies present in the runtime en-

vironment. Based on this model, the required run-

time behavior can be automatically derived and map-

ped to operational technologies. This enables the de-

sign of a self-service tool for software developers to

automatically transform their microservice into a self-

conﬁguring microservice tailored for the targeted run-

time environment (cf. Figure 2).

Microservices are constructed as independently

deployable units. Thus, we assume some kind of ser-

AUTOGENIC: Automated Generation of Self-conﬁguring Microservices

Transformation

Modeling Deployment

AUTOGENIC

Nexus

Service Bundle

Self-configuring

Service Bundle

Software Developers

Operations Personnel

Runtime Environment

Specification

Runtime Environment

Config.

Store

A P I

Service

Registry

A P I

Figure 2: Overview of the AUTOGENIC approach.

vice bundle, which contains all the required artifacts

to deploy a microservice. An important part of the

service bundle is the topology model describing the

topology of containers and related artifacts (e.g., con-

tainer images) (Kehrer and Blochinger, 2017). The

topology model contains all information required to

automatically deploy a corresponding microservice to

a runtime environment. However, besides specifying

the containers and their relationships for deployment

purposes, developers also have to consider the dyna-

mic conﬁguration of these containers during runtime

(cf. Section 2.1).

To specify the conﬁguration requirements, we uti-

lize the existing topology model, which is part of

every service bundle. Following a model-based ap-

proach, we enable developers to annotate each contai-

ner speciﬁed in the topology model with a conﬁgura-

tion model. Figure 3 shows two containers, which are

part of a topology model, each annotated with a con-

ﬁguration model. The conﬁguration model contains

one or more conﬁguration operations. These conﬁgu-

ration operations are deﬁned by a name and specify

an implementation artifact as well as inputs. The im-

plementation artifact refers to an executable artifact in

the container (e.g., a shell script) that must be invoked

to execute the conﬁguration operation on a technical

level. The inputs can be deﬁned as key-value pairs,

which are passed to the implementation artifact upon

execution. In case of our exemplary microservice, a

shell script for connecting to the MySQL database

might be speciﬁed as implementation artifact of the

conﬁgure db operation attached to the wordpress con-

tainer (cf. Figure 3).

Additionally, we enable the use of functions to

specify input values for conﬁguration operations.

Functions can be used to reference dynamic attri-

bute values of entities in the topology model, e.g.,

IP addresses of modeled containers. Referring to our

exemplary microservice, the conﬁgure db operation

speciﬁes an input named mysql ip with the function

getIPAddress() that retrieves the IP address of the

mysql container (cf. Figure 3).

A core idea of the AUTOGENIC approach is to

automatically execute conﬁguration operations whe-

never their input values change. Since these input

values are stored in the runtime environment, a cor-

responding event-trigger has to be registered to this

change event in the environment. The callback of this

event-trigger is given by the implementation artifact

speciﬁed for the corresponding conﬁguration opera-

tion. This enables reactive conﬁguration and dyna-

mic bindings among containers. A typical example

is the conﬁgure db operation of the wordpress contai-

ner. Reconﬁguration and thus execution of the /conﬁ-

gure.sh script is required whenever the IP address of

the mysql container changes in the environment.

The topology model enhanced with the proposed

conﬁguration model (cf. Figure 3) is packaged into a

service bundle and then passed as input to a service

that we call AUTOGENIC Nexus (cf. Figure 2). The

AUTOGENIC Nexus takes a developer-supplied ser-

vice bundle as input and generates a self-conﬁguring

ConnectsTo

wordpress

mysql

Configuration Model

configure_db:

implementation: /configure.sh

inputs:

mysql_ip: mysql.getIPAddress()

update_cache:

implementation: …

inputs:

key: value

…

upd at e_settings:

implementation: …

inputs:

key: value

…

Figure 3: Containers annotated with conﬁguration models.

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

service bundle as output. The transformation applied

adds self-conﬁguration mechanisms to each container

on a technical level based on the conﬁguration opera-

tions speciﬁed. The AUTOGENIC Nexus is maintai-

ned by operations personnel and provided as a self-

service tool to software developers. It encapsulates

the speciﬁcs of the target runtime environment. This

might be the access mechanisms of the conﬁguration

store and the service registry used in the runtime envi-

ronment (e.g., APIs) as well as event-dispatching me-

chanisms to trigger developer-supplied implementa-

tion artifacts. The selection of these technologies is an

operational decision and thus should be handled trans-

parently to application development. The runtime en-

vironment speciﬁcation has to be considered during

the implementation of the AUTOGENIC Nexus.

Implemented once, the AUTOGENIC Nexus pro-

vides a self-service tool for developers, which ge-

nerates self-conﬁguring service bundles targeted to

a speciﬁc runtime environment without any know-

ledge on operational technologies employed. The

self-conﬁguring service bundle contains all required

information to deploy a microservice in an automated

manner (cf. Figure 2). This approach ensures the se-

paration of concerns principle in the DevOps context

in line with our design guidelines deﬁned above.

Following our model-based approach, service

bundles can be developed independently of the run-

time environment. This leads to several beneﬁts com-

pared to microservice conﬁguration on programming

level, i.e., directly implementing the API of a conﬁgu-

ration store or service registry: (1) Different techno-

logies can be used to implement the required conﬁgu-

ration behavior depending on the target runtime envi-

ronment; (2) Developers do not have to build triggers

for conﬁguration operations by wiring APIs. Conﬁgu-

ration operations are executed automatically whene-

ver their input values change; (3) Logical identiﬁers

of containers are only used in the model and not in

the containers themselves leading to higher reusabi-

lity. Further, these identiﬁers are private to the topo-

logy model of a single microservice and thus cannot

be used by other microservices. Note that this is an

important requirement, e.g., to prevent direct database

access from outside the service (O’Hanlon, 2006).

4 AUTOGENIC METHOD

The AUTOGENIC method speciﬁes the steps to trans-

form an existing service bundle including its conﬁgu-

ration models into a self-conﬁguring service bundle.

This method describes the transformation performed

by the AUTOGENIC Nexus on a conceptual level to

guide the runtime-speciﬁc implementation by opera-

tions personnel. Accordingly, our method describes

the transformation independently of (1) the modeling

language used for the topology and conﬁguration mo-

dels, (2) the container format employed for virtuali-

zation, (3) operational technologies in the target run-

time environment, and (4) event-dispatching mecha-

nisms used to build event-triggers. As a result, our

method supports various combinations, which can be

found in practice (cf. Section 5). Figure 4 depicts the

AUTOGENIC method. We describe its steps in the

following.

4.1 Assumptions

This method requires a service bundle that contains a

topology model enhanced with conﬁguration models.

Moreover, build speciﬁcations for each container are

assumed to be part of the service bundle.

4.2 Step 1: Scan Topology Model &

Build Speciﬁcations

We assume that each container speciﬁed in the topo-

logy model links its conﬁguration model and a build

speciﬁcation. Whereas the conﬁguration model des-

cribes the desired conﬁguration behavior, the build

speciﬁcation can be used to derive the current runtime

behavior of the container. In this step, conﬁguration

models and container build speciﬁcations are scanned

to derive a set of Transformation Requirements (TR).

TRs describe the requirements that have to be addres-

sed during the transformation and are provided as in-

put to the next steps. Scanning the conﬁguration mo-

dels leads to the following TRs:

• A StoreKeyValueRequirement describes a key-

value pair, which is used as input for a speciﬁc

conﬁguration operation. This key-value pair has

to be stored in the runtime environment during de-

ployment (e.g., by using a conﬁguration store).

• A KeyWatchRequirement describes the require-

ment to watch the value of a speciﬁc input key

stored in the environment. Whenever the value re-

lated to this key changes, the corresponding con-

ﬁguration operation should be executed.

• An AttributeWatchRequirement describes the re-

quirement to watch the value of a deﬁned attri-

bute such as the IP address of a speciﬁc contai-

ner. Whenever this value changes the correspon-

ding conﬁguration operation should be executed.

Additionally, the build speciﬁcations have to be scan-

ned. On a technical level this is performed by sim-

ply recognizing keywords (descriptors) that are deﬁ-

AUTOGENIC: Automated Generation of Self-conﬁguring Microservices

Service Bundle

Container Image

Build Specification

Topology Model

Scan Topology Model

& Build Specifications

Create Build

Specifications

Create Event-Triggers

& Callback-Operations

Create Self-Configuring

Service Bundle

Build Container ImagesAutomated Deployment

Artifact

Repository

Figure 4: Steps of the AUTOGENIC method.

ned by the container format employed. Scanning the

build speciﬁcations leads to the following TR:

• An EntryPointRequirement describes the en-

trypoint of a container. This is an executable run

at container startup (Turnbull, 2014).

TRs allow the automated construction of a new

container image (cf. Section 4.4), which fulﬁlls

the same functional requirements as the developer-

supplied container image, but additionally contains

self-conﬁguration mechanisms.

4.3 Step 2: Create Event-Triggers &

Callback-Operations

In this step, the TRs derived have to be addressed.

Therefore, implementation artifacts provided by de-

velopers have to be bound as callbacks to change

events in the environment. Environment-speciﬁc

event-dispatching mechanisms are employed for this

purpose. At the same time, functional aspects of a

developer-supplied container should be retained.

StoreKeyValueRequirements are addressed by an

initial setup process executed at each container’s star-

tup. This setup process stores the required inputs

in the environment. After the initial setup process,

each container runs the executable captured in its En-

tryPointRequirement.

KeyWatchRequirements as well as AttributeWat-

chRequirements have to be met by installing an event-

trigger for the corresponding conﬁguration operation,

which executes the implementation artifact speciﬁed

whenever input values change. The implementation

of event-triggers depends on the technologies em-

ployed in the target runtime environment. This inclu-

des mapping the schema of operational data structures

as well as deﬁning access methods and protocols for

the conﬁguration store and service registry.

This step results in a set of technological artifacts,

which ensure dynamic conﬁguration of each contai-

ner with respect to the target runtime environment.

The generated technological artifacts automatically

trigger the implementation artifacts supplied by the

developer every time a conﬁguration value changes in

the environment.

4.4 Step 3: Create Build Speciﬁcations

To combine the developer-supplied container image

with the technological artifacts generated in Step 2,

a new build speciﬁcation is created for each contai-

ner speciﬁed in the topology model. This build spe-

ciﬁcation is built on top of the existing build speci-

ﬁcation that deﬁnes the developer-supplied microser-

vice. It basically adds the generated technological ar-

tifacts (cf. Section 4.3) and installs required software

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

packages. In this context, a build speciﬁcation tem-

plate may be used, which contains the settings deri-

ved from the runtime environment speciﬁcation, e.g.,

commands to install required software.

4.5 Step 4: Create Self-Conﬁguring

Service Bundle

Since conﬁguration operations are now managed by

the corresponding container itself, the conﬁguration

models are not required for deployment purposes. In

this step, a new service bundle is generated, which

provides a portable means to deploy the generated

self-conﬁguring microservice to the target runtime en-

vironment.

4.6 Step 5: Build Container Images

Finally, the container images of the newly generated

build speciﬁcations captured in the self-conﬁguring

service bundle have to be built. Besides creating con-

tainer images, they have to be pushed to an artifact

repository, which can be accessed during deployment.

4.7 Automated Deployment

The generated service bundle provides a means to au-

tomatically deploy the generated self-conﬁguring mi-

croservice to the target runtime environment. There-

fore, container images can be retrieved from the arti-

fact repository speciﬁed in the service bundle.

5 AUTOGENIC PROTOTYPE

In this section, we present an AUTOGENIC Nexus

prototype. The AUTOGENIC method describes how

to transform a service bundle including the conﬁgura-

tion models to low-level technical aspects of the target

runtime environment. Hence, we have to make four

decisions with respect to an implementation: First,

we have to specify the modeling language used for

topology and conﬁguration models. Possible opti-

ons are any custom modeling language supporting

our assumptions, domain-speciﬁc languages of con-

tainer management systems such as Kubernetes, Ma-

rathon, and Docker Swarm as well as the TOSCA

standard (OASIS, 2013). Secondly, we have to choose

a container format such as Docker, Application Con-

tainer (appc) Speciﬁcation

, or the speciﬁcation of

the Open Container Initiative (OCI)

. Thirdly, we

https://github.com/appc/spec.

https://www.opencontainers.org.

have to deﬁne the operational technologies of the

target runtime environment. Typical examples are

Consul, Etcd, ZooKeeper, SkyDNS

, Eureka

, and

Doozer

. Finally, event-dispatching mechanisms are

required. Options include speciﬁc tooling to access

operational technologies as well as ContainerPilot

In this section, we describe a prototype employing

the emerging TOSCA standard as modeling language,

which also contains a format for service bundles. We

rely on the TOSCA standard because it provides a

language to specify topology models of microservi-

ces in a portable manner and concepts to specify de-

pendencies in the model. The TOSCA concept of

Lifecycle Operations already provides us with com-

patible modeling constructs to specify conﬁguration

operations. Further, we employ Docker

as contai-

ner virtualization technology, Consul as conﬁguration

store and service registry, and ContainerPilot to build

event-triggers. We describe TOSCA and a TOSCA-

based service bundle of an exemplary microservice in

the following. Moreover, we present an exemplary

runtime environment speciﬁcation. On this basis, we

present the implementation of our prototype.

5.1 Topology and Orchestration

Speciﬁcation for Cloud Applications

(TOSCA)

The Topology and Orchestration Speciﬁcation for

Cloud Applications (TOSCA) aims at standardizing

a modeling language for portable cloud services (OA-

SIS, 2013). Therefore, cloud services are captured as

topology graphs modeled in form of a Topology Tem-

plate. The nodes in the topology are modeled as Node

Templates.

Since a Topology Template is an abstract descrip-

tion of a service topology, Deployment Artifacts such

as container images (e.g., Docker Images) are linked

to Node Templates as depicted in Figure 5. Node

Templates also deﬁne Lifecycle Operations. These

Lifecycle Operations are implemented by Implemen-

tation Artifacts such as shell scripts (cf. Figure 5).

Additionally, TOSCA provides a type system that

allows the deﬁnition of custom types such as Node

Types or Artifact types. These type deﬁnitions and the

Topology Template are captured in a so-called Service

Template. A TOSCA orchestrator processes a Service

Template to instantiate nodes. Modeling a TOSCA-

https://github.com/skynetservices/skydns.

https://github.com/Netﬂix/eureka.

https://github.com/ha/doozerd.

https://github.com/joyent/containerpilot.

https://docker.com.

AUTOGENIC: Automated Generation of Self-conﬁguring Microservices

create

start

Lifecycle

Operations

Shell

ScriptShell

Script

Implementation Artifacts

Deployment Artifact

implements

…

Node Template

Docker

Image

Figure 5: TOSCA Artifacts and Lifecycle Operations.

based cloud service results in a self-contained, por-

table service model called Cloud Service ARchive

(CSAR) that can be used to deploy service instances

in all TOSCA-compliant environments. The CSAR

contains the Service Template and related Deploy-

ment Artifacts as well as Implementation Artifacts.

In the Simple Proﬁle in YAML V1.0 (OASIS, 2016),

TOSCA provides modeling constructs for containers

as well as TOSCA Functions. TOSCA Functions

allow referencing values of entities in the Topology

Template, which have to be resolved during runtime.

5.2 TOSCA-based Service Bundle

In this section, we describe a TOSCA-based service

bundle of our exemplary microservice described in

Section 2.2. This service bundle will be used as exem-

plary input for our prototypical implementation. Due

to space limitations, we only present representative

parts of the service bundle.

We use a CSAR as service bundle, which contains

a description of the microservice topology by me-

ans of a Topology Template. The Topology Template

speciﬁes Node Templates for the containers, namely

wordpress, memcached, mysql, and backup. Listing 1

shows the Node Template of wordpress. It speciﬁes

its Deployment Artifact, which is a Docker Image (cf.

Listing 1, line 6–9). This Docker Image is provided to

the Create Operation to instantiate the node (cf. Lis-

ting 1, line 12–13). To specify our conﬁguration mo-

dels, we append an additional Lifecycle Interface na-

med Conﬁgure for conﬁguration operations (cf. Lis-

ting 1, line 14–22). This Lifecycle Interface provides

the information required by the AUTOGENIC Nexus.

The conﬁgure db Operation speciﬁes an Imple-

mentation Artifact /conﬁgure.sh, which requires four

input values. The host of the database is speci-

ﬁed with a TOSCA Function (cf. Listing 1, line 18).

A TOSCA Function speciﬁes an input value that

depends on runtime information. In this case, the IP

1 wordpress:

2 ...

3 contains: [wordpress_build]

4 ...

5 artifacts:

6 wp_image:

7 file: wordpress-custom

8 type: tosca.artifacts.Deployment.Image.Container.Docker

9 repository: custom_repository

10 interfaces:

11 Standard:

12 create:

13 implementation: wp_image

14 Configure:

15 configure_db:

16 implementation: /configure.sh

17 inputs:

18 DB_HOST: { get_attribute: [mysql, ip_address] }

19 DB_USER: myuser

20 DB_PASSWORD: pw

21 DB_NAME: mydb

22 ...

Listing 1: wordpress Node Template in YAML.

1 wordpress_build:

2 ...

3 artifacts:

4 build_spec:

5 file: artifacts/wordpress/Dockerfile

6 type: cst.artifacts.Deployment.BuildSpec.Docker

7 properties:

8 image_name: wordpress-custom

9 repository: custom_repository

10 interfaces:

11 Standard:

12 create:

13 implementation: build_spec

Listing 2: wordpress build Node Template in YAML.

address of mysql is required to connect to the data-

base.

Container images only capture ﬁle system changes

and thus do not provide information on how they have

been created. They are constructed of a set of layers

each described by a corresponding build speciﬁcation

such as a Dockerﬁle. However, the TOSCA standard

does not allow the deﬁnition of build speciﬁcations

describing the construction of container images. To

resolve this issue, we introduced the concept of Con-

tained Nodes (Kehrer and Blochinger, 2017) to model

build speciﬁcations for each Node Template. There-

fore, a container Node Template such as wordpress

links a contained Node Template (cf. Listing 1, line

3). The wordpress build Node Template speciﬁes the

build speciﬁcation of the corresponding wordpress-

custom Docker Image (cf. Listing 2, line 4–9) requi-

red to deploy wordpress. In this case, the build speci-

ﬁcation is a Dockerﬁle.

The containers memcached, mysql, and backup are

modeled in an analogous manner and specify their

Deployment Artifacts as well as conﬁguration opera-

tions as explained above.

5.3 Runtime Environment Speciﬁcation

The target runtime environment addressed by our pro-

totype is a TOSCA-based container management sy-

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

stem from previous work (Kehrer and Blochinger,

2017), which can be used to deploy a TOSCA-based

service bundle. We selected Consul to store con-

ﬁguration and endpoint information in the environ-

ment, which provides both a key-value store to store

conﬁguration data and service discovery mechanisms.

The Consul ecosystem provides a rich set of tools to

access stored data. To enable self-conﬁguring micro-

services, we have to additionally select technologies

used to bind conﬁguration operations to events. We

chose ContainerPilot, which is an open-source pro-

ject developed by Joyent. ContainerPilot resembles

the UNIX concept of process supervision by provi-

ding a supervisor middleware for processes running

inside a software container. Besides, it provides in-

tegration with service discovery tooling, which we

apply to bind event-triggers to conﬁguration operati-

ons. ContainerPilot is conﬁgured by passing a conﬁ-

guration ﬁle, which contains the processes to be run.

A Docker Registry

is employed as artifact reposi-

tory, i.e., to push and retrieve container images (cf.

Figure 4).

5.4 Implementation

In this section, we outline how we implemented our

prototype in Java. Therefore, we describe the imple-

mentation counterparts of step 1–5 as deﬁned in the

AUTOGENIC method (cf. Section 4).

Step 1: A TOSCA Parser loads the TOSCA-based

service bundle and transforms the Service Tem-

plate into an internal object. Our RequirementScan-

ner derives TRs from the Topology Template, na-

mely StoreKeyValueRequirements, KeyWatchRequi-

rements, and AttributeWatchRequirements. Moreo-

ver, the RequirementScanner scans the Dockerﬁles

linked in the Service Template to identify EntryPoin-

tRequirements.

Step 2: We employ ContainerPilot version 3.1.1 as

process supervisor for each container. A Container-

Pilot conﬁguration ﬁle is used to create event-triggers

for conﬁguration operations. The key-value pairs des-

cribed by StoreKeyValueRequirements are stored in

Consul with an initial setup process executed on con-

tainer startup. Moreover, the executable captured in

an EntryPointRequirement is executed after the initial

setup process.

KeyWatchRequirements and AttributeWatchRe-

quirements require the installation of event-triggers.

Technically, we register separate background proces-

ses in the ContainerPilot conﬁguration ﬁle. These

background processes run Consul watches with the

https://hub.docker.com/ /registry.

Consul command line tool, which can be used to get

informed whenever a value changes. We use Con-

sul watches to trigger envconsul

whenever an input

value of a conﬁguration operation changes in Con-

sul. Envconsul then executes the implementation arti-

fact of the corresponding conﬁguration operation and

provides the inputs as environment variables. The

resulting technological artifacts are a ContainerPilot

conﬁguration ﬁle and scripts for the initial setup pro-

cess.

Step 3: To create build speciﬁcations, we use a ﬁle

template for each Dockerﬁle, which installs a Consul

client, envconsul, and ContainerPilot. Additionally,

we add the artifacts generated in Step 2. The proces-

sing is implemented based on Apache FreeMarker

which is an open-source template engine.

Step 4: A new contained Node Template is added to

each container Node Template, which is built on top

of the developer-supplied contained Node Template

and links the generated build speciﬁcation. Besides,

the Deployment Artifacts of the container Node Tem-

plates are updated with the name of the new container

images. The generated Service Template is added to

a newly generated service bundle, which contains all

build speciﬁcations and technological artifacts requi-

red to build the container images.

Step 5: To build container images, we assume a

Docker Engine running on the host. We connect to

the Docker Engine by using the Docker-Client

li-

brary developed by Spotify. Docker-Client connects

to the Docker Engine through the default UNIX dom-

ain socket provided to control Docker-speciﬁc functi-

onality. We build the required container images des-

cribed by the generated build speciﬁcations and push

them to the artifact repository speciﬁed in the Topo-

logy Template.

6 EVALUATION

To evaluate our prototype, we employ the formerly

described service bundle of our exemplary microser-

vice (cf. Section 5.2). The underlying runtime en-

vironment speciﬁcation is given in Section 5.3. We

present two experiments to analyze the overhead re-

sulting from the transformation performed by the AU-

TOGENIC Nexus prototype.

In the baseline experiment, we build all developer-

supplied container images speciﬁed in the service

https://github.com/hashicorp/envconsul.

http://freemarker.org.

https://github.com/spotify/docker-client.

AUTOGENIC: Automated Generation of Self-conﬁguring Microservices

bundle and measure the total generation time. We

deﬁne the total generation time as the accumulated

time, which is required to build these container ima-

ges and to push the generated container images to the

artifact repository. In the transformation experiment,

we run the prototype to generate a self-conﬁguring

service bundle and measure the total transformation

time. We deﬁne the total transformation time as the

elapsed time from the start of the prototype to the

point, where all steps of the AUTOGENIC method are

successfully completed. This also includes pushing

the generated container images to the corresponding

artifact repository (cf. Figure 4).

We executed our experiments on a CentOS 7 vir-

tual machine with 2 vCPUs clocked at 2.6 GHz, 4

GB RAM, and 40 GB disk running in our OpenStack-

based cloud environment. The virtual machine pro-

vides an OpenJDK Runtime Environment 1.8.0 and

Docker Engine 1.12.6. For building container ima-

ges, we rely on the Docker Engine API v1.24. As

artifact repository, we run a private Docker Registry

v2.6 on localhost. We executed ten independent runs

for each experiment and measured the total generation

time and the total transformation time, respectively.

In the baseline experiment, we build a single con-

tainer image for each container. These container ima-

ges are built based on the build speciﬁcation spe-

ciﬁed in the service bundle. However, all contai-

ner images require base images from the Docker-

Hub. The wordpress container requires downloa-

ding php:5.6-apache

with 377.7 MB, memcached

requires debian:stretch-slim

with 55.24 MB, mysql

requires oraclelinux:7-slim

with 117.6 MB, and

backup requires python:2.7.14-jessie

with 679.3

MB. To ensure that we measure the total generation

time without caching, we cleared the Docker cache

and the Docker Registry before every run. In this con-

text, caching of container images relates to the inter-

mediate layers stored by Docker to speed up future

build processes. Based on the measurements, we cal-

culated an average total generation time of (882 ±38)

seconds.

In the transformation experiment, we ran our pro-

totype to measure the total transformation time. The-

refore, all required container images are built and

pushed to the artifact repository. This includes the

developer-supplied container images as well as con-

tainer images generated by the AUTOGENIC Nexus

prototype. Again, we cleared the Docker cache and

the Docker Registry before every run. Based on the

https://hub.docker.com/ /php.

https://hub.docker.com/ /debian.

https://hub.docker.com/ /oraclelinux.

https://hub.docker.com/ /python.

measurements, we calculated an average total trans-

formation time of (1349 ± 16) seconds.

The transformation adds an average overhead in

size of 67.8 MB per container image. This is largely

related to ContainerPilot and Consul-speciﬁc tooling.

Note that the container images built in the baseline ex-

periment are not self-conﬁguring. Additional manual

effort would be required to enable the same features,

thus also leading to larger image sizes.

In summary, the transformation applied by our

prototype results in an average overhead of 467 se-

conds to enable the AUTOGENIC approach. However,

we enable software developers to implement their mi-

croservices independent of operational technologies,

which saves time during development. Moreover, our

model-based approach leads to several beneﬁts such

as portability of microservice implementations and

the separation of concerns for software developers

and operations personnel (cf. Section 3).

The overhead measured is basically related to

building additional container images, which include

the required self-conﬁguration mechanisms. Note

that the measurements depend on the size of required

and generated container images, the network band-

width for downloading the required base images, and

the location of the artifact repository. Thus, the re-

ported values may be different in a real world sce-

nario. Furthermore, we identiﬁed several opportuni-

ties to speed up the transformation performance such

as building container images concurrently and storing

required software packages locally. Obviously, ca-

ching techniques offer another opportunity for perfor-

mance tuning.

7 RELATED WORK

Our approach aims at facilitating the development of

self-conﬁguring microservices by introducing an ab-

straction layer between software developers and ope-

rations personnel. Implementing the AUTOGENIC

method leads to a self-service tool that enables de-

velopers to take responsibility for the dynamic con-

ﬁguration of their microservices independently of the

runtime environment. Using self-service tools and au-

tomation is a commonly applied approach for suppor-

ting DevOps (H

uttermann, 2012).

Microservices require decentralized management

and prefer choreography over orchestration (Fowler,

2017; Newman, 2015; Zimmermann, 2017). The aut-

hors of (Schermann et al., 2016) state that more re-

search on choreography rather than orchestration is

required. Self-conﬁguring microservices are a solu-

tion to ensure dynamic conﬁguration without relying

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science

on centralized orchestration. Following the AUTO-

GENIC approach, conﬁguration is managed by each

container and thus executed in a decentralized, event-

based manner.

Several approaches exist to build microservices

with decentralized conﬁguration capabilities. In (Tof-

fetti et al., 2015) and (Toffetti et al., 2017) distri-

buted in-memory key-value stores are employed to

communicate changes among components. Whereas

this results in a similar technical implementation, our

model-based approach contributes to the ease of deve-

lopment of self-conﬁguring microservices. Thus, de-

velopers are relieved of the burden of wiring their mi-

croservice implementations with operational techno-

logies. In (Stubbs et al., 2015), the authors present

a solution to the service discovery problem based on

Serf

. Their approach proposes an additional Serf-

node container, which manages a required container

instance. In contrast, we add an environment-speciﬁc

supervisor (e.g., ContainerPilot) directly to an exis-

ting container image. Whereas Serfnodes do not re-

quire building new container images, they require ex-

tra conﬁguration and only solve the service discovery

problem. Moreover, the presented solution does not

provide the same abstraction level compared to our

model-based approach, which uses conﬁguration mo-

dels to deﬁne operational behavior on a higher level.

Microservice chassis

such as Spring Cloud

might be used to dynamically conﬁgure microservi-

ces. However, microservice chassis are bound to

a speciﬁc programming language and are limited to

supported operational tooling. Netﬂix Prana

provi-

des a side car for services based on the NetﬂixOSS

ecosystem. This enables the use of Java-based

NetﬂixOSS libraries for microservices written in ot-

her programming languages. Registrator

enables

service discovery features for Docker containers by

watching the runtime environment. In comparison,

we provide a simple means to software developers and

separate the logical deﬁnition of conﬁguration opera-

tions from their technical implementation. Following

this model-based approach enables the use of diffe-

rent technological solutions depending on the target

runtime environment.

https://www.serf.io.

http://microservices.io/patterns/microservice-

chassis.html.

http://projects.spring.io/spring-cloud.

https://github.com/Netﬂix/Prana.

https://netﬂix.github.io.

https://github.com/gliderlabs/registrator.

8 CONCLUSION

In this paper, we presented the AUTOGENIC appro-

ach to automatically generate self-conﬁguring micro-

services. We introduced a novel approach to decou-

ple software developers and operations personnel by

separating their concerns. This leads to microservice

development independent of the target runtime envi-

ronment and thus also enables ﬂexibility for operati-

ons personnel with respect to technological decisions

and changes. Furthermore, we presented the AUTO-

GENIC method, which describes the steps to generate

self-conﬁguring microservices. The method is des-

cribed on a conceptual level and thus applicable to

any modeling language and runtime environment ful-

ﬁlling the proposed assumptions. We validated our

approach by implementing a prototype based on the

TOSCA standard and state of the art technologies.

In the future, we plan to investigate use cases

beyond dynamic conﬁguration. Our prototype pro-

vides evidence that also monitoring features might be

automatically enabled for developer-supplied micro-

services. Following the AUTOGENIC approach, re-

quired monitoring endpoints can be added in a trans-

parent manner thus hiding the monitoring solution

employed from software developers.

ACKNOWLEDGEMENTS

This research was partially funded by the Ministry

of Science of Baden-W

urttemberg, Germany, for the

Doctoral Program ’Services Computing’.

REFERENCES

Balalaie, A., Heydarnoori, A., and Jamshidi, P. (2016). Mi-

croservices architecture enables devops: Migration to

a cloud-native architecture. IEEE Software, 33(3):42–

52.

Fowler, M. (2017). Microservices Resource Guide. URL:

https://martinfowler.com/microservices/.

uttermann, M. (2012). DevOps for Developers. Apress.

Kehrer, S. and Blochinger, W. (2017). Tosca-based con-

tainer orchestration on mesos - two-phase deployment

of cloud applications using container-based artifacts.

Computer Science Research and Development.

Kookarinrat, P. and Temtanapat, Y. (2016). Design and im-

plementation of a decentralized message bus for mi-

croservices. In 2016 13th International Joint Confe-

rence on Computer Science and Software Engineering

(JCSSE), pages 1–6.

Kratzke, N. and Quint, P.-C. (2017). Understanding cloud-

native applications after 10 years of cloud computing

AUTOGENIC: Automated Generation of Self-conﬁguring Microservices

- a systematic mapping study. Journal of Systems and

Software, 126:1 – 16.

Lewis, J. and Fowler, M. (2014). Microservices a

deﬁnition of this new architectural term. URL:

https://martinfowler.com/articles/microservices.html.

Leymann, F., Breitenb

ucher, U., Wagner, S., and Wettinger,

J. (2017). Native Cloud Applications: Why Monolithic

Virtualization Is Not Their Foundation, pages 16–40.

Springer International Publishing, Cham.

Newman, S. (2015). Building Microservices. O’Reilly Me-

dia, Inc., 1st edition.

OASIS (2013). Topology and orchestration speciﬁ-

cation for cloud applications (tosca) version 1.0,

committee speciﬁcation 01. URL: http://docs.oasis-

open.org/tosca/TOSCA/v1.0/cs01/TOSCA-v1.0-

cs01.html.

OASIS (2016). Tosca simple proﬁle in yaml ver-

sion 1.0, committee speciﬁcation 01. URL:

http://docs.oasis-open.org/tosca/TOSCA-Simple-

Proﬁle-YAML/v1.0/cs01/TOSCA-Simple-Proﬁle-

YAML-v1.0-cs01.html.

O’Hanlon, C. (2006). A conversation with werner vogels.

Queue, 4(4):14:14–14:22.

Pahl, C., Brogi, A., Soldani, J., and Jamshidi, P. (2017).

Cloud container technologies: a state-of-the-art re-

view. IEEE Transactions on Cloud Computing,

PP(99):1–1.

Pahl, C. and Jamshidi, P. (2016). Microservices: A syste-

matic mapping study. In Proceedings of the 6th In-

ternational Conference on Cloud Computing and Ser-

vices Science - Volume 1 and 2, CLOSER 2016, pa-

ges 137–146, Portugal. SCITEPRESS - Science and

Technology Publications, Lda.

Schermann, G., Cito, J., and Leitner, P. (2016). All the Ser-

vices Large and Micro: Revisiting Industrial Practice

in Services Computing, pages 36–47. Springer, Berlin,

Heidelberg.

Stubbs, J., Moreira, W., and Dooley, R. (2015). Distributed

systems of microservices using docker and serfnode.

In 2015 7th International Workshop on Science Gate-

ways, pages 34–39.

Toffetti, G., Brunner, S., Bl

ochlinger, M., Dudouet, F.,

and Edmonds, A. (2015). An architecture for self-

managing microservices. In Proceedings of the 1st

International Workshop on Automated Incident Mana-

gement in Cloud, AIMC ’15, pages 19–24, New York,

NY, USA. ACM.

Toffetti, G., Brunner, S., Bl

ochlinger, M., Spillner, J.,

and Bohnert, T. M. (2017). Self-managing cloud-

native applications: Design, implementation, and

experience. Future Generation Computer Systems,

72(Supplement C):165 – 179.

Turnbull, J. (2014). The Docker Book: Containerization is

the new virtualization. James Turnbull.

Zimmermann, O. (2017). Microservices tenets. Computer

Science - Research and Development, 32(3-4):301–

310.

CLOSER 2018 - 8th International Conference on Cloud Computing and Services Science