Semi-Automated Smell Resolution in Kubernetes-Deployed Microservices

Jacopo Soldani

, Marco Marin

o and Antonio Brogi

Department of Computer Science, University of Pisa, Pisa, Italy

Keywords:

Microservices, Kubernetes, Architectural Smells, Architectural Refactoring.

Abstract:

Microservices are getting commonplace, as their design principles enable obtaining cloud-native applications.

Ensuring that applications adheres to microservices’ design principles is hence crucial, and this includes

resolving architectural smells possibly denoting violations of such principles. To this end, in this paper

we propose a semi-automated methodology for resolving architectural smells in microservices applications

deployed with Kubernetes. Our methodology indeed automatically detects architectural smells by analyzing

the Kubernetes manifest ﬁles specifying an application’s deployment, and it can also generate the refactoring

templates for resolving such smells. We also introduce

KubeFreshener

, an open-source prototype of our

methodology, which we use to assess it in practice based on a controlled experiment and a case study.

1 INTRODUCTION

Microservices gained momentum in enterprise IT, as

they enable realizing so-called cloud-native applica-

tions (Balalaie et al., 2018; Yussupov et al., 2020).

Microservices are essentially service-oriented architec-

tures satisfying additional key design principles, e.g.,

ensuring microservices’ independent deployability and

horizontal scalability, or isolating failures (Zimmer-

mann, 2017). Ensuring that microservices’ design

principles are satisﬁed is hence crucial for a microser-

vices application to truly deliver their promises (Taibi

and Lenarduzzi, 2018; Herrera et al., 2023).

(Neri et al., 2020) singled out architectural smells,

which could possibly denote violations of microser-

vices’ key design principles. An architectural smell

is the observable symptom of a bad (though uninten-

tional) decision while designing an application, which

may negatively impact on its adherence to design prin-

ciples (Garcia et al., 2009), and which can be resolved

through refactoring. For this reason, (Neri et al., 2020)

also elicited the architectural refactorings that enable

resolving the occurrence of such smells.

In this paper, we propose a “black-box” method-

ology to resolve the occurrence of four architectural

smells from (Neri et al., 2020) in microservices appli-

cations. Our methodology is “black-box” in the sense

that it abstracts from the internals of containerized

microservices, which are typically polyglot (Soldani

https://orcid.org/0000-0002-2435-3543

https://orcid.org/0000-0003-2048-2468

et al., 2018). We rather automatically detect architec-

tural smells in microservices applications by analyz-

ing the manifest ﬁles specifying their deployment in

Kubernetes, the de-facto standard for microservices

deployment (Indrasiri and Siriwardena, 2018). We

also show how to generate templates for resolving the

detected architectural smells, by refactoring the mani-

fest ﬁles specifying their deployment. The resolution

templates specify the refactorings needed for resolving

the detected smells, which should be completed by

suitably adapting an application’s microservices and

their deployment to ensure that the application’s func-

tionalities are preserved. For this reason, we say that

our methodology enables semi-automatically resolv-

ing architectural smells in microservices applications.

To assess the practical applicability of our method-

ology, we introduce

KubeFreshener

, an open-source

prototypical implementation that we use to run exper-

iments. We indeed discuss the application of

Kube-

Freshener

in a controlled experiment based on a toy

application deployment, showing that it can effectively

detect injected architectural smells and generate their

resolution templates. We also illustrate a case study

applying

KubeFreshener

to an existing, third-party

application, in which we detect architectural smells

and generate the templates of the refactorings allowing

to resolve them. In the case study, we also discuss how

an existing smell can lead to a possible violation of a

microservices’ key design principle, while the same

does not hold in the refactored application deployment

(even if some further adaptation would be needed to

Soldani, J., Marinò, M. and Brogi, A.

Semi-Automated Smell Resolution in Kubernetes-Deployed Microservices.

DOI: 10.5220/0011845500003488

In Proceedings of the 13th International Conference on Cloud Computing and Services Science (CLOSER 2023), pages 34-45

ISBN: 978-989-758-650-7; ISSN: 2184-5042

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

suitably complete the refactoring).

In summary, the main contributions of this paper

are the following:

(i)

We propose a semi-automated methodology to

resolve smells in microservices applications de-

ployed with Kubernetes,

(ii)

we introduce

KubeFreshener

, a prototypical im-

plementation of the proposed methodology, and

(iii)

we evaluate our methodology by exploiting

KubeFreshener

to run a controlled experiment

and a case study.

The paper is organized as follows. Section 2 provides

background on microservices’ architectural smells and

refactorings. Section 3 introduces our semi-automated

smell resolution methodology, whose prototype and

evaluation are presented in Sections 4 and 5, respec-

tively. Finally, Sections 6 and 7 discuss related work

and draw some concluding remarks, respectively.

2 BACKGROUND

We hereafter recap four microservices’ architectural

smells from (Neri et al., 2020), together with the refac-

toring allowing to resolve their occurrence.

Multiple Services per Deployment Unit. (Neri et al.,

2020) consider containers (such as Docker containers)

as the deployment units for microservices, and ex-

plain how placing multiple microservices in the same

container would constitute a microservices’ architec-

tural smell. One such placement would indeed vio-

late the principle of independent deployability of mi-

croservices: if two microservices would be shipped

within the same container, spawning/destroying such

container would necessarily result in deploying/unde-

ploying both microservices at the same time. More

generally, by placing two microservices in the same

deployment unit (whether this being a Docker con-

tainer or a Kubernetes pod), such microservices would

operationally depend one another, as it would not be

possible to launch a new instance of one of the two,

without also launching an instance of the other.

The multiple services per deployment unit smell

can be resolved by refactoring the deployment so that

each microservice is deployed with a different deploy-

ment unit. This means that each microservice should

be packaged in a different container, and that it should

run in a different pod, if using Kubernetes.

We here generalize the smell called multiple services in

one container in (Neri et al., 2020) to deployment units, as

pods (and not containers) are Kubernetes’ deployment units.

Endpoint-based Service Interaction. This architec-

tural smell occurs when a microservice invokes a spe-

ciﬁc instance of another microservice, e.g., since no

load balancer is used to handle the requests arriving

to the instances of the invoked microservice. If this

is the case, the horizontal scalability of the invoked

microservice is compromised: when scaling out such

microservice by adding new replicas, the newly intro-

duced replicas would not be reached by the invokers,

hence only wasting resources (Neri et al., 2020).

An endpoint-based service interaction smell can

be resolved by introducing a message router, which

handles the requests sent to a microservice, e.g., by

balancing the load among its replicated instances.

No API Gateway. When an application lacks an API

gateway, external clients must necessarily invoke its

microservices directly. The result is a situation similar

to that of endpoint-based service interactions, with in-

vokers this time being the external clients (rather than

other microservices from the same application). If this

is the case, the horizontal scalability of invoked mi-

croservices is compromised, similarly to what happens

for the case of endpoint-based service interactions.

A no API gateway smell can be resolved by in-

troducing a message router working as API gateway

for the affected microservice. The introduced gate-

way handles the requests of external clients by suitably

routing them to the affected microservice’s instances.

Wobbly Service Interaction. The interaction between

two microservices is “wobbly” when a failure of the

invoked microservice can trigger a cascading failure

in the invoker, hence compromising the principle of

isolation of failures of microservices. This typically

happens when a microservice invokes the function-

alities offered by another microservice, without any

solution for handling the possibility of the invoked

service to fail or be unresponsive.

A wobbly service interaction can be resolved by in-

troducing timeouts or circuit breakers to handle the fail-

ure of invoked microservices. Timeouts are a simple

yet effective solution for a microservice to stop wait-

ing for an answer from another microservice, when

the latter is unresponsive, e.g., since it failed or due

to network issues. Circuit breakers instead wrap the

invocations from a microservice to another. The cir-

cuit breaker is initially “closed”, meaning that it just

forwards the invocations to the wrapped microservice,

and monitors its execution to detect and count failing

invocations. Once the frequency of failures reaches a

given threshold, the circuit breaker trips and “opens”

the circuit. All further calls to the wrapped microser-

vice will “safely fail”, as the circuit breaker will im-

mediately return an error message to the callers.

Semi-Automated Smell Resolution in Kubernetes-Deployed Microservices

3 METHODOLOGY

The overall idea is to process the manifest ﬁles speci-

fying the deployment of a microservices application

in Kubernetes, so as to detect occurrences of architec-

tural smells and generate their resolution templates.

We hereafter illustrate how to do it for the architectural

smells from (Neri et al., 2020) recapped in Section 2,

separately. For each architectural smell, we actually

ﬁrst recap its related Kubernetes objects, to then il-

lustrate how to exploit such objects to enact smell

detection and resolution template generation.

3.1 Multiple Services per Deployment

Unit

The multiple services per deployment unit happens

when different microservices are shipped within the

same deployment unit (Section 2). If this happens,

such microservices operationally depend one another,

and it would not be possible to launch a new instance

of one of them, without also launching an instance of

the others (Neri et al., 2020).

3.1.1 Related Kubernetes Objects

Pods constitute the smallest deployment units that can

be spawned and managed by Kubernetes (Kubernetes,

2022). They can be created directly with manifests

of type

Pod

, or – more typically – from workload

resources speciﬁed in manifests of type

Deployment

(Poulton, 2022).

Essentially, a pod is a group of one or more contain-

ers, with a speciﬁcation for how to run them (Figure 1).

When running multiple containers, they are always

co-located and co-scheduled, and run in a shared con-

text, e.g., with shared storage and network resources.

For this reasons, and following the guidelines given in

the documentation of Kubernetes (Kubernetes, 2022),

co-located containers should be used for initialization

purposes, through so-called init containers, or when

they constitute a single cohesive unit of service, with

one “main container” running the service and a set

of supporting containers implementing the sidecar,

ambassador, or adapter patterns (Richardson, 2018).

Figure 1 provides an example of

Deployment

, for a

service named

catalogue

, which runs from the main

container named

catalogue

. The ﬁgure also includes

an init container for loading the catalogue itself, and

an example of supporting container, viz., a sidecar

dynatrace

container deployed to monitor

catalogue

At the same time, the

Deployment

in Figure 1 includes

another container than

catalogue

, viz.,

users

. The

latter is not an init container, nor identiﬁed as an im-

kind : D eplo y ment

met a data :

name : c atalo gue

label s :

serv i ce : c atal o gue

spec :

tem p late :

in i tCo n tai ners :

- name : catalogu e - loade r

image : example / c a t a logue - l o ader

con tain e rs :

- name : c a talo g ue

image : example / catal o gue

- name : d y natr a ce

image : dynatr ace / o neage n t

- name : user s

image : example / u s ers

res o urce s :

req u ests :

memor y : 50 Mi

met a da ta :

label s :

serv i ce : cat al ogue

sel e ct or :

mat chLa be ls :

serv i ce : cat al ogue

rep l ic as : 2

Figure 1: Example of pod speciﬁcation, through a manifest

of type Deployment.

plementation of a sidecar, ambassador, or adapter (ac-

cording to the above listed criteria). The container

users

should hence be considered an occurrence of

the multiple services per deployment unit smell.

3.1.2 Smell Detection

The overall idea is to ignore init, sidecar, ambassador,

and adapter containers when looking for occurrences

of the multiple services per deployment unit smell.

Their use is intentional and intended to suitably run

the service running in the “main container” of the pod

(Kubernetes, 2022), with the main container identiﬁed

as the ﬁrst container that is neither an init container

nor an implementation of a sidecar, ambassador, or

adapter. The same does not hold for any other con-

tainer deployed alongside the main container, which

may be running another service, hence witnessing a

possible occurrence of the multiple services per de-

ployment unit smell. An example of this is the

users

container in Figure 1, which is deployed alongside the

main

catalogue

container, while not being an init,

sidecar, ambassador, or adapter container.

The above idea is realized by considering each

manifest ﬁle of type

Pod

Deployment

, whose

init-

Containers

ﬁeld is directly skipped. Then, each con-

tainer in the

containers

section, other than the main

container, is processed as follows: if the container is

an implementation of a sidecar, ambassador, or adapter

pattern, it is ignored. This is identiﬁed by checking

whether the properties

name

image

of the container

include the keywords sidecar, ambassador, or adapter,

or whether they include the name or Docker image of

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

Table 1: Examples of software distributions known to imple-

ment sidecar, ambassador, or adapter patterns.

Software Name (Docker Image)

Datadog (

datadog/agent

), Dynatrace (

dynatrace/

oneagent

), Hitch (

hitch

), Logstash (

logstash

OAuth2 Proxy (

bitnami/oauth2-proxy

), Prometheus

(bitnami/prometheus)

software distributions known to implement a sidecar,

ambassador, or adapter pattern (Table 1). In any other

case, since the container may run another service than

the main container, it is considered to denote a multiple

services per deployment unit smell.

Going back to the example in Figure 1,

catalo-

gue

is identiﬁed as the main container, as we ignore

catalogue-loader

(init container) and

dynatrace

(which appears in Table 1). Instead, the

users

con-

tainer does not satisfy any of the conditions for being

ignored, and it is hence considered an occurrence of

the multiple services per deployment unit smell.

3.1.3 Resolution Template Generation

The detected occurrences of the multiple services per

deployment unit smell can be resolved by implement-

ing the only known refactoring, namely by keeping

only one service in the pod and moving the others to

different pods. This is done by keeping the service

running in the main container in the pod, together with

any init, sidecar, ambassador, or adapter containers

therein. Each other container possibly running a ser-

vice is instead migrated to a different

Deployment

whose

metadata

indicate that it runs a service named

as the container’s

name

, and which preserves the origi-

nal conﬁguration of the container itself.

Figure 2 provides an example of what above, by

displaying the

Deployment

s obtained by refactoring

that in Figure 1 to resolve the multiple services per

deployment unit smell due to

users

. The latter is

removed from the

Deployment

catalogue

(Fig-

ure 2a) and moved to a new

Deployment

(Figure 2b).

The name of the new

Deployment

is the same as that

of the migrated container, and it preserves its original

conﬁguration. It indeed indicates the same

requests

on resources, and it is set to be replicated twice.

3.2 Endpoint-Based Service Interaction

The endpoint-based service interaction smell occurs

when a microservices directly invokes another mi-

croservice’s instance, e.g., with no intermediate com-

ponent balancing the requests arriving to the replicated

instances of the invoked service (Neri et al., 2020).

kind : D eplo y ment

met a da ta :

name : c at alog u e

label s :

serv i ce : cat al ogue

spec :

tem p la te :

in i tCo n tai ners :

- name : catalogu e - loade r

image : exa m pl e / catalogue - l oa de r

con ta iner s :

- name : c a talo g ue

image : exa m pl e / cat al ogue

- name : d y natr a ce

image : dy n atra c e / one ag ent

met a da ta :

label s :

serv i ce : cat al ogue

sel e ct or :

mat chLa be ls :

serv i ce : cat al ogue

rep l ic as : 2

(a)

kind : D eplo y ment

met a da ta :

name : use r s

label s :

serv i ce : users

spec :

tem p la te :

con ta iner s :

- name : user s

image : exa m pl e / users

res o urce s :

req u es ts :

memor y : 50 Mi

met a da ta :

label s :

serv i ce : users

sel e ct or :

mat chLa be ls :

serv i ce : users

rep l ic as : 2

(b)

Figure 2: Refactoring templates for resolving the multiple

services per deployment unit smell in Figure 1.

3.2.1 Related Kubernetes Objects

Pods are dinamically spawned/destroyed to match the

desired state for a deployed microservices application.

Each pod gets its own IP address, which can be ﬁxed,

however also meaning that different instances of the

same microservice will get different IP addresses (Ku-

bernetes, 2022).

Kubernetes

Service

s are message routing com-

ponents allowing to decouple invokers and invoked

microservices. They indeed provide an abstract way to

expose the multiple replicas of the invoked microser-

vice’s pod with the same hostname. When receiving

a request sent to a microservice’s hostname, a Kuber-

netes

Service

forwards such request to one of the

corresponding pod’s instances (Kubernetes, 2022).

The association between a Kubernetes

Service

and the pods it handles is speciﬁed through the

selector

ﬁelds in both manifest ﬁles. An exam-

ple of this is given in the manifest ﬁle in Figure 3,

which displays a Kubernetes

Service

for handling

the trafﬁc sent to the

catalogue

microservice (Fig-

Semi-Automated Smell Resolution in Kubernetes-Deployed Microservices

kind : S e rv ic e

met a da ta :

name : catalo g u e - serv ic e

spec :

type : C lu ster I P

sel e ct or :

serv i ce : cat al ogue

Figure 3: Example of Kubernetes Service.

ure 2a). The hostname of the target microservice is

set to

catalogue-service

, in the

metadata

ﬁeld of

the manifest in the ﬁgure. The association

Service

Deployment

is instead speciﬁed in the

selector

ﬁelds

of the manifest ﬁles in Figure 2a and Figure 3. Finally,

the manifest ﬁle in Figure 3 indicates that the type of

the Kubernetes

Service

ClusterIP

, which means

that it is reachable only from within the cluster where

the application is deployed (Kubernetes, 2022).

3.2.2 Smell Detection

When processing the manifest ﬁles specifying an ap-

plication’s deployment, we check whether there exists

at least one Kubernetes

Service

associated with each

Pod

Deployment

specifying the deployment of a

microservice that can be invoked by other microser-

vices.

A microservice with no associated Kubernetes

Service

is considered an occurrence of the endpoint-

based service interaction smell. Indeed, without a

Kubernetes

Service

routing the requests to the pos-

sible replicas of the pod running such microservice,

its instances’ endpoints should necessarily be directly

contacted by the invoking microservices.

For instance, suppose that we process the manifest

ﬁles in Figures 2 and 3, and that all the microservices

deployed with such manifest ﬁles may get invoked by

other microservices. We would detect that there is no

Kubernetes

Service

handling the requests sent to the

users

microservice, whose

Deployment

speciﬁes that

such microservice is replicated twice (Figure 2b). Any

other microservice invoking

users

should therefore

directly invoke any of the two replicas, hence possi-

bly witnessing the occurrence of an endpoint-based

service interaction smell on users.

3.2.3 Resolution Template Generation

The occurrence of an endpoint-based service interac-

tion smell can be resolved by introducing a Kubernetes

Service

to handle the requests sent to the replicas of

the pod running the affected microservice. This is done

by creating a new manifest ﬁle specifying the newly in-

troduced Kubernetes

Service

of type

ClusterIP

, to

We assume the list of invoked microservices to be pro-

vided as input, e.g., as described in Section 4.

kind : S e rv ic e

met a da ta :

name : users - s e rv ic e

spec :

type : C lu ster I P

sel e ct or :

serv i ce : users

Figure 4: Refactoring template for resolving the endpoint-

based service interaction smell affecting users.

ensure that the affected microservice can still be acces-

sible only from within the cluster where the application

is running. The newly introduced Kubernetes

Service

is then associated with the workload resource specify-

ing the deployment of the affected microservice, either

reusing the

selector

already speciﬁed therein, or by

adding a new selector in both manifest ﬁles.

The above refactoring is exempliﬁed in Figure 4,

which shows the Kubernetes

Service

introduced as

template for resolving the smell on

users

. Given that

the

Deployment

users

(Figure 2b) already speciﬁes

selector

, we reuse the same

selector

in the newly

introduced Kubernetes Service.

3.3 No API Gateway

The no API gateway smell occurs whenever the clients

of a microservices directly invoke any of its microser-

vices. This does not mean that there is no API gateway

set for the whole application, but rather that no API

gateway is used to handle the external requests sent to

the affected microservices (Neri et al., 2020).

3.3.1 Related Kubernetes Objects

The

Deployment

Pod

specifying the deployment of

a microservice allow specifying that the pod where it

runs can be directly accessed from external clients.

This can be done by setting the properties

host-

Network

and

hostPort

(Kubernetes, 2022). The prop-

erty

hostNetwork

can be set for the whole pod, allow-

ing all its containers to be accessibile from all the net-

work interfaces of the host where the pod runs. Instead,

the property

hostPort

can be set on each container

running in a pod, to expose it on a given port of the

host where it runs. Both properties are however con-

sidered privileged operations, which should be used to

enable speciﬁc network plugins, rather than to expose

microservices outside of the cluster where they run

(VMWare, 2020).

Pods should better be exposed by exploiting the

Kubernetes objects devoted to that purpose. For in-

stance, Kubernetes Services allow to handle the traf-

ﬁc arriving to pods’ replicas not only from other mi-

croservices running in the same cluster, but also from

external clients. Indeed, by specifying Kubernetes

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

Table 2: Examples of software distributions known to imple-

ment API gateways.

Software Name (Docker Image)

Apache APISIX (

apache/apisix

), Envoy (

envoy/

envoyproxy

), Kong (

kong/kong-gateway

), NGINX

(nginx), Traeﬁk (traefik)

kind : D eplo y ment

met a da ta :

name : p ay me nts

label s :

serv i ce : pay m ents

spec :

tem p la te :

con ta iner s :

- name : p a yment s

image : exa m pl e / pay m ents

ports :

co n tai n erP o rt : 80

hos t Po rt : 4040

met a da ta :

label s :

serv i ce : pay m ents

sel e ct or :

mat chLa be ls :

serv i ce : pay m ents

Figure 5: Example of no API gateway smell.

Service

s of type

NodePort

LoadBalancer

, such

Service

s get accessible from outside of the cluster

where they run. A Kubernetes

Service

of type

Node-

Port

is exposed on a given port of the host where the

Service

runs, while those of type

LoadBalancer

are

exposed externally by using a cloud provider’s load

balancer (Kubernetes, 2022). Another possibility to

expose microservices externally, yet through Kuber-

netes

Service

s is to deﬁne Ingress nodes redirecting

external requests to such Services (Poulton, 2022).

3.3.2 Smell Detection

No API gateway smells are detected by analyzing

each

Pod

Deployment

specifying how to deploy

microservice. If such

Pod

Deployment

speciﬁes ei-

ther of the

hostNetwork

and

hostPort

properties, the

deployed component is exposed outside of the cluster

where it runs. This is not a problem if the component

is implementing an API gatweay itself. This is identi-

ﬁed by checking whether the properties

name

image

of the main container include the keyword gateway,

or whether they include the name or Docker image

of software distributions typically used to implement

API gateways (Table 2). In any other case, since the

exposed container may run a microservice that is di-

rectly accessible by external clients, it is considered to

denote a no API gateway smell.

Consider, for instance, the manifest ﬁle in Figure 5,

which speciﬁes the

Deployment

of the

payments

mi-

croservice. The property

hostPort

of the main con-

tainer is set to expose

payments

on port

4040

. Exter-

nal clients can hence directly invoke

payments

, with-

out passing through any API gateway (even if one is

set for

payments

itself). This, together with the fact

that the main container does not satisfy the above listed

criteria for identifying implementations of API gate-

ways, makes

payments

to be considered as affected

by a no API gateway smell.

3.3.3 Resolution Template Generation

no API gateway

smell due to the use of

host-

Network

hostPort

can be resolved by removing

them, however considering that they were speciﬁed to

expose a microservice externally, which is something

to be preserved. The refactoring template hence also

consists of introducing a “basic API gateway”, namely

a message routing component for handling external

requests and forwarding them to the affected microser-

vice (Neri et al., 2020). For this reason, by default, we

introduce a Kubernetes

Service

of type

NodePort

which is accessible by external client on a given port

of the host where it runs. The port mapping is the

same as that indicated in the original conﬁguration of

the affected microservice, if available. Otherwise, the

default choice is to use port

8080

, as a placeholder for

later adapting the port mapping to better ﬁt the appli-

cation’s setting. A possible alternative is introducing a

Kubernetes

ClusterIP Service

, and conﬁguring an

Ingress node to listen on the port where the microser-

vice was exposed (or on port

8080

, as a placeholder)

and to redirect incoming requests to the newly intro-

duced Kubernetes Service.

Figure 6 provides an example of the default res-

olution template generation. The ﬁgure displays the

updated

Deployment

payments

and a new Kuber-

netes

Service

, obtained by refactoring its original

Deployment in Figure 5. The Deployment is updated

by removing

hostPort

, and it is associated with the

newly introduced Kubernetes

Service

by reusing the

already available

selector

. Such

Service

is of type

NodePort

and provides the same port mapping as in

the original conﬁguration of

payments

, being it acces-

sible on port

4040

. It implements a basic API gateway,

meaning that it implements the message routing mech-

anism needed to handle the requests sent to

payments

by suitably routing them to any pod instantiated from

the Deployment in Figure 6a.

3.4 Wobbly Service Interaction

A wobbly service interaction occurs whenever a mi-

croservice invokes another without mechanisms for

The association between the newly introduced Ku-

bernetes

Service

and the workload resource is realized

via

selector

s, similarly to the case of

endpoint-based

service interactions (Section 3.2).

Semi-Automated Smell Resolution in Kubernetes-Deployed Microservices

kind : D eplo y ment

met a da ta :

name : p ay me nts

label s :

serv i ce : pay m ents

spec :

tem p la te :

con ta iner s :

- name : p a yment s

image : exa m pl e / pay m ents

ports :

co n tai n erP o rt : 80

met a da ta :

label s :

serv i ce : pay m ents

sel e ct or :

mat chLa be ls :

serv i ce : pay m ents

(a)

kind : S e rv ic e

met a da ta :

name : payments - se rv ic e

spec :

type : N od eP ort

sel e ct or :

serv i ce : pay m ents

ports : con ta iner s :

- name : p a yment s

image : exa m pl e / pay m ents

ports :

- port : 80

tar ge tPor t : 80

nod e Po rt : 4040

(b)

Figure 6: Refactored manifest ﬁles, obtained by resolving

the no API gateway smell in Figure 5.

tolerating the failure of the invoked microservice, such

as, e.g., timeouts or circuit breakers (Section 2).

3.4.1 Related Kubernetes Objects

Timeouts and circuit breakers can be set by managing

the trafﬁc sent to a pod with Istio, a Kubernetes-native

trafﬁc management system. Istio’s

VirtualService

allow explicitly setting a

timeout

to indicate the maxi-

mum amount of time after which the interaction with a

microservice is considered to have failed (Istio, 2022).

For instance, the

VirtualService

in Figure 7a sets a

timeout

0.5s

for requests sent to

payments

(Fig-

ure 6a).

Instead, Istio’s

DestinationRule

s allow setting

outlierDetection

policy, through which circuit

breakers can be set by indicating This is done by set-

ting the maximum number of tolerated consecutive

errors before the circuit breaker trips (Istio, 2022). For

instance, the

DestinationRule

in Figure 7b sets a

circuit breaker for

users

(Figure 2b), which trips after

two consecutive errors are returned by users.

3.4.2 Smell Detection

We focus on detecting the lack of timeouts and circuit

breakers only in the manifest ﬁles specifying the de-

ployment of a microservices application. Similarly

to the detection of endpoint-based service interac-

kind : V irt u alS ervi ce

spec :

hosts :

- pay me nts

http :

- route :

- de st ina t ion :

host : p ay me nts

time o ut : 0.5 s

(a)

kind : D est inat ion R ule

spec :

host : use r s

tr a ffi c Pol i cy :

ou t lie rDe t ect ion :

co n se c uti ve5 xxE r ror s : 2

(b)

Figure 7: Examples of (a) timeouts and (b) circuit breakers

deﬁned with Istio.

tions, we start from an input list of invokable mi-

croservices, and we check whether the

Deployment

Pod

specifying their deployment are associated with

VirtualService

s or

DestinationRule

s setting time-

outs or circuit breakers, respectively. Each microser-

vice whose pod deployment is not associated to one

such

VirtualService

DestinationRule

is con-

sidered as affected by the wobbly service interaction

smell, as the microservices sending it requests would

not tolerate its failure – unless timeouts or circuit

breakers are set in their source code, which are not

considered by our “black-box” approach.

For instance, suppose that we process the manifest

ﬁles in Figures 2 to 7, and that all the microservices

deployed with such manifest ﬁles may get invoked

by other microservices. There is a

VirtualService

setting a timeout for

payments

(Figure 7a) and a

DestinationRule

setting a circuit breaker for

users

(Figure 7b). The same does not hold for

catalogue

for which there is no timeout or circuit breaker set

in the manifest ﬁles specifying its deployment in Ku-

bernetes. This means that the microservices invoking

catalogue

may not tolerate its failure, hence possibly

failing in cascade – unless they have fault tolerance

mechanisms set in their source code. For this reason,

and given that we apply a “black-box” approach by

focusing on what we can observe from the Kubernetes

manifest ﬁles, we would detect a wobbly service inter-

action smell on catalogue.

3.4.3 Resolution Template Generation

A wobbly service interaction affecting a microservice

can be resolved by introducing a

VirtualService

setting a timeout for the requests sent to such microser-

vice, or by introducing a

DestinationRule

setting a

circuit breaker for such requests. This can be done

by essentially mirroring the conﬁguration in the man-

ifest ﬁles in Figure 7. The

VirtualService

resolu-

tion approach is applied by default, by introducing

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

kind : V irt u alS ervi ce

spec :

hosts :

- ca t alog u e

http :

- route :

- des tina ti on :

host : c at alog u e

time o ut : 0.5 s

Figure 8: Refactoring template for resolving the wobbly

service interaction smell affecting catalogue.

a manifest ﬁle specifying a

VirtualService

, whose

hosts

and

destination

ﬁelds indicate that it handles

the requests sent to the affected microservice, with a

timeout

set to

0.5s

. Alternatively, the

Destination-

Rule

resolution approach can be applied by intro-

ducing manifest ﬁle specifying a

DestinationRule

whose

host

ﬁeld indicates that it handles the requests

sent to the affected microservice, with a

traffic-

Policy

conﬁguring a circuit breaker that trips after

two consecutive errors.

Figure 8 displays the manifest ﬁle introduced as

resolution template for the wobbly service interaction

smell affecting the

catalogue

microservice. The man-

ifest ﬁle speciﬁes a

VirtualService

that handles the

requests sent to

catalogue

, which is listed within the

host

ﬁeld, and which is indicated as the

destination

of the

route

of the

VirtualService

itself. The mani-

fest ﬁle also sets a

timeout

0.5s

for such a

route

hence setting a timeout for all requests sent to the

targeted microservice (Istio, 2022).

3.5 Summary and Discussion

Sections 3.1 to 3.4 illustrate how to automatically de-

tect architectural smells by analyzing the manifest ﬁles

specifying the deployment of a microservices appli-

cation in Kubernetes. Our methodology is “black-

box”, as we analyze only the information speciﬁed

in Kubernetes, by abstracting from the internals of

the containerized microservices forming an applica-

tion. This enables supporting polyglot microservices

applications, by focusing on their deployment Kuber-

netes, which is the de-facto standard for microservices

deployment (Indrasiri and Siriwardena, 2018).

At the same time, an architectural smell automat-

ically identiﬁed by our methodology does not neces-

sarily mean that some microservices’ design principle

is truly violated. For instance, we may detect a multi-

ple services per deployment smell on a pod with two

containers even if one actually implements a sidecar,

but its name does not include the keyword sidecar or

it does not run from a known implementation of side-

cars. We may also detect a wobbly service interaction

smell affecting a microservice, but the microservices

cmd-

handler

k8s-types

freshener

config-

types

YAML

config

manifests

YAML

yaml-

handler

main

Figure 9: The architecture of KubeFreshener.

invoking it may implement some timeout or circuit

breaker directly within their source code, which we

cannot see. This is however in line with the deﬁnition

of architectural smell themselves: they are only pos-

sible symptoms of bad design decisions, which may

possibly result in a violation of the design principles of

microservices in our case (Neri et al., 2020). Anyhow,

to reduce the rate of false postives, the prototypical im-

plementation of our methodology (Section 4) already

enables to specify which smells to ignore on which mi-

croservices, e.g., since such microservices are known

to implement the necessary countermeasures in their

source code.

Similarly, the proposed resolution templates au-

tomatically adapt the deployment of a microservices

application in Kubernetes. The proposed refactoring

exploits Kuberntes elements to introduce what needed,

but the same refactoring could be achieved by suitably

adapting the source code of affected microservices,

or using other extensions of Kubernetes. Also, while

the update/generation of Kubernetes manifest ﬁles can

be fully automated, the overall resolution approach is

semi-automated. The microservices application and

its deployment in Kubernetes may indeed need some

further adaptation to continue working. For instance, a

microservice may need to be updated to invoke the Ku-

bernetes

Service

introduced to resolve an endpoint-

based service interaction smell, or init containers may

need to be added to the

Deployment

s introduced to

resolve multiple services per deployment unit smells.

4 PROTOTYPE

We hereafter introduce

KubeFreshener

, a Rust im-

plementation of the semi-automated smell resolution

methodology described in Section 3.

KubeFreshener

is open-source and publicly available on GitHub.

4.1 Architecture of KubeFreshener

KubeFreshener

is structured in six Rust modules, as

displayed in Figure 9. The main module implements

a command-line interface to run the proposed semi-

automated smell resolution by coordinating the other

modules. In particular, it ﬁrst invokes the cmd-handler

https://github.com/di-unipi-socc/kube-freshener.

Semi-Automated Smell Resolution in Kubernetes-Deployed Microservices

to process the command-line inputs, which include

the analysis to run and the options to customize such

analysis. The main module then invokes the yaml-

handler to parse the YAML manifests specifying the

deployment of an application in Kubernetes, which are

transformed in Rust objects by relying on the object

model deﬁned by k8s-types. The yaml-handler also

parses the YAML conﬁg ﬁle specifying the analysis’

conﬁguration, e.g., which smells to ignore on which

services, yet instantiating Rust objects by relying on

the object model deﬁned by k8s-types. The obtained

objects are returned to the main module, which passes

them to the freshener. The latter processes such ob-

jects by implementing the semi-automated smell iden-

tiﬁcation described in Section 3, returning a report on

identiﬁed smells to the main module. If the analysis

is also speciﬁed to generate the refactoring templates,

the freshener also updates the objects representing

the application deployment in Kubernetes accordingly.

The main module ﬁnally invokes the yaml-handler to

streamline the (possibly updated) objects representing

the application deployment back to YAML-based Ku-

bernetes manifest ﬁles, and it outputs the results of the

smell analysis on the command-line.

4.2 Using KubeFreshener

After cloning its GitHub repository,

KubeFreshener

should be conﬁgured by placing the manifest ﬁles spec-

ifying the Kubernetes deployment to be analyzed in

a new subfolder called

manifests

. The run of

Kube-

Freshener

can be further conﬁgured by editing a ﬁle

config.yaml

, which enables specifying (i) the list of

invoked services

and (ii) the list

ignore smells

indicating which architectural smells should not be

checked on which microservices. The list (i) enables

checking for endpoint-based and wobbly service in-

teractions only those microservices that are actually

invoked by other microservices, as described in Sec-

tions 3.2 and 3.4. Instead, the list (ii) enables reducing

the rate of false positives, by allowing to indicate, e.g.,

which microservices are known to implement what

needed to avoid architectural smells in their source

code (as discussed in Section 3.5)

Once the conﬁguration is completed,

KubeFreshe-

ner can be launched by issuing the command

$ cargo run analyze.

This will run

KubeFreshener

in detection mode only,

meaning that it will output only the list of architectural

smells that have been automatically identiﬁed on the

considered deployment, if any (Figure 10). By speci-

fying option “

-s

”, instead,

KubeFreshener

will also

generate the templates for the needed refactorings, by

! [ Mult i ple con tain e rs per unit ]

(* ) pay me nts is dep lo ye d a l ongs i de search -

en gine , which m ay not be a si de ca r

Hint : de p lo y pa y ments and search - e n gi ne

sep ar atel y

! [No AP I Gat e wa y ]

(* ) pay me nts has H ostN etwo rk set , but it

ma y not imp l emen t any me s sage rout in g

Hint : uns e t H ostN e two r k on p ay ments .

! [ Endpoint - ba s e d in te rac t ion ]

(* ) Ser v ic e ca ta logu e is invo k ed by o t her

micr o se rv ic e s , bu t there ’ s no ass o ciat ed

Kub er nete s Se r vi ce

Hint : add a Kub er nete s Se r vi ce h an dling

th e req ue sts sent to c a talo g ue

! [ Wo bb ly I nt era c tion ]

(* ) Ser v ic e named ca ta logu e is r eache d by

anot h er s e rvice wit ho ut any cir cu it b r ea ke r

or t im eo ut .

Hint : sol v e it by a dd in g a cir c ui t br e ak er

an d / or a t i me ou t in be tw ee n .

Figure 10: Example of output returned by

KubeFreshener

users-

manager

orders

carts

catalogue

search-

engine

frontend

shipping

payments

mysql-

users

mongo-

orders

mongo-

products

Figure 11: Architecture of the toy microservices application

in our controlled experiment. Boxes denote services, while

oriented arcs denote service interactions.

adapting the manifest ﬁles in the folder

manifests

described in Section 3.

5 EVALUATION

To assess the practical applicability of our semi-

automated smell resolution methodology, we ap-

plied

KubeFreshener

in a controlled experiment (Sec-

tion 5.1) and a case study (Section 5.2).

5.1 Controlled Experiment

The objective of our controlled experiment was to test

whether our methodology can effectively detect the

considered architectural smells and generate their res-

olution templates. We hence devised a Kubernetes de-

ployment for the toy microservices application in Fig-

ure 11. The deployment was set to include each of the

four architectural smells considered in Section 3. The

microservices

catalogue

and

search-engine

were

included in the same

Deployment

to inject a multiple

services per deployment unit smell. A no API gate-

way smell was instead injected on

payments

by setting

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

ordercustomer

apache-

http

catalog

Figure 12: Architecture of the microservices application in

our case study.

hostNetwork

true

in its

Deployment

. Finally, we

injected endpoint-based and wobbly service interac-

tion smell on

catalogue

, which was not associated

with a Kubernetes

Service

routing incoming requests

among its possible replicas, nor with any Istio-based

timeout or circuit breaker.

We conﬁgured

KubeFreshener

to process the spec-

iﬁed deployment, while also indicating the list of mi-

croservices that are invoked by other microservices.

We then run

KubeFreshener

, which successfully de-

tected all the four injected smells, as displayed in Fig-

ure 10. Finally, we tested the smell resolution, observ-

ing that

KubeFreshener

was capable of generating

the smell resolution templates, which are available

alongside the input manifest ﬁles on GitHub.

5.2 Case Study

The objective of our case study was to assess the appli-

cability of our methodology to a third-party microser-

vices application. We therefore conﬁgured

KubeFre-

shener

to process an existing demo application from

(Wolff, 2016), whose Kubernetes deployment is pub-

licly available on GitHub.

Given the application’s

documented architecture (Figure 12), we also conﬁg-

ured

KubeFreshener

to consider that the microser-

vices

customer

order

, and

catalog

are invoked

by another microservice. We then run

KubeFreshe-

ner

, which identiﬁed three wobbly service interaction

smells, as shown in Figure 13.

We further experimented on the identiﬁed smells,

by artiﬁcially injecting a deterministic failure of

catalog

. The source code of

catalog

was indeed up-

dated to never reply when invoked, to check whether

apache-http

was failing in cascade. We run the up-

dated deployment, and invoked

apache-http

to stim-

ulate its interaction with

catalog

. As a result, we

observed that

apache-http

never replied to our invo-

cations, hence witnessing a cascading failure due to

the failure injected in catalog.

We hence re-run

KubeFreshener

to automatically

resolve the identiﬁed wobbly service interaction smells.

The refactored manifest ﬁles – which are publicly

https://github.com/di-unipi-socc/kube-freshener/tree/

main/data/examples/controlled-exp.

https://github.com/ewolff/microservice-kubernetes.

! [ Wo bb ly I nt era c tion ]

(* ) Ser v ic e named cu s tomer is r e ac hed by

anot h er s e rvice wit ho ut any cir cu it b r ea ke r

or t im eo ut .

Hint : sol v e it by a dd in g a cir c ui t br e ak er

an d / or a t i me ou t in be tw ee n .

! [ Wo bb ly I nt era c tion ]

(* ) Ser v ic e named order is re a ch ed by

anot h er s e rvice wit ho ut any cir cu it b r ea ke r

or t im eo ut .

Hint : sol v e it by a dd in g a cir c ui t br e ak er

an d / or a t i me ou t in be tw ee n .

! [ Wo bb ly I nt era c tion ]

(* ) Ser v ic e named cat al og is r ea ch ed by

anot h er s e rvice wit ho ut any cir cu it b r ea ke r

or t im eo ut .

Hint : sol v e it by a dd in g a cir c ui t br e ak er

an d / or a t i me ou t in be tw ee n .

Figure 13: Output of KubeFreshener in our case study.

available on GitHub

– include three new

Virtual-

Service

s setting timeouts for

customer

order

, and

catalog

as described in Section 3.4. Such manifest

ﬁles were used “as-is” to repeat the above described ex-

periment. As a result, we observed that

apache-http

came back replying when interacting with

catalog

even if the latter did not reply to its invocations.

At the same time,

apache-http

returned a 500

error when

catalog

was not replying. This witnesses

why our smell resolution is semi-automated: while

the updated deployment may resolve the smell-related

issue, the application would require the refactoring to

be completed to tolerate the failures of

catalog

. In

this particular case, for instance, we would also need

to update

apache-http

to better handle the situation

when the newly introduced timeouts expire.

6 RELATED WORK

Various existing approaches contribute to resolving

architectural smells in microservices. The closest to

ours is perhaps that in (Soldani et al., 2021), which

models the architecture of a microservices application

in the OASIS standard TOSCA (OASIS, 2020) and

enact a model-based analysis to detect and reason on

how to refactor the architectural smells in (Neri et al.,

2020). (Soldani et al., 2021) also allows reconstructing

the TOSCA modeling of a microservices application

from its Kubernetes deployment. At the same time, the

TOSCA modeling abstacts from the actual deployment

of services in pods, hence not allowing to resolve the

multiple services per pod smell (as we do). Also, our

approach differs from that in (Soldani et al., 2021),

since we can automatically generate the refactoring

templates for resolving identiﬁed smells, if any.

https://github.com/di-unipi-socc/kube-freshener/tree/

main/data:examples/case-study.

Semi-Automated Smell Resolution in Kubernetes-Deployed Microservices

(Pigazzini et al., 2020) instead automatically iden-

tiﬁes three architectural smells from (Taibi and Lenar-

duzzi, 2018), viz., cyclic dependencies, hardcoded

endpoints, and shared persistence. This is done by

adapting Arcan (Fontana et al., 2017), which statically

analyzes the Java sources of given software projects, to

detect the above three smells in microservices. Hence,

(Pigazzini et al., 2020) differs from our methodology

since it targets Java-based microservices, while our

“black-box” analysis enables applying it to polyglot

microservices. Also, we try to go beyond just detect-

ing architectural smells, by automatically generating

refactoring templates for resolving detected smells.

Other approaches worth mentioning are (Balalaie

et al., 2018), (Haselb

ock et al., 2017), and (Ponce

et al., 2022a), which all focus on enabling to design

“smell-free” applications. (Balalaie et al., 2018) and

(Haselb

ock et al., 2017) actually support the migra-

tions of applications to microservices, by providing

patterns and decision models for such task, respec-

tively. (Ponce et al., 2022a) instead proposes a trade-

off analysis for resolving security smells in microser-

vices applications, with such smells taken from (Ponce

et al., 2022b). We further support the design of “smell-

free” microservices applications, as we can automati-

cally detect architectural smells from their Kubernetes

deployment, while also generating refactoring tem-

plates to resolve detected smells.

Finally, it is worth relating our contribution to exist-

ing solutions for identifying and resolving architectural

smells in classical service-oriented applications. (Gar-

cia et al., 2009) and (Sanchez et al., 2015) detect smells

in the design of a single service, given its speciﬁcation.

(Arcelli et al., 2019), (Fontana et al., 2017), and (Vidal

et al., 2015) instead provide programming language-

speciﬁc analyses to resolve the smells contained in the

source code of a single service. We instead focus on

resolving architectural smells in a whole application,

by considering the interactions occurring among its

microservices and their deployment. Also, by enacting

a “black-box” analysis, we natively work with poly-

glot microservices. The above approaches are anyhow

complementary to ours: they can be used to analyze

and refactor the internals of a microservice, while ours

can be used to resolve the architectural smells of an

overall microservices application.

In summary, to the best of our knowledge, ours

is the ﬁrst solution for semi-automatically resolving

architectural smells in polyglot microservices appli-

cations, by analyzing and generating refactoring tem-

plates of their deployment in Kubernetes.

7 CONCLUSIONS

We illustrated a semi-automated solution for resolving

smells in microservices applications. The main contri-

butions of our paper are actually threefold, viz., (i) a

methodology that automatically detects smell occur-

rences by analyzing the manifest ﬁles specifying an ap-

plication’s deployment in Kubernetes, which also gen-

erates the templates of the necessary refactorings by

suitably adapting such manifest ﬁles, (ii)

KubeFreshe-

ner

, a prototypical implementation of our methodol-

ogy, and (iii) the application of

KubeFreshener

to a

controlled experiment and a case study, with the goal

of assessing our methodology’s practical applicability.

As pointed out in Section 3.5, an architectural

smell automatically identiﬁed by our methodology

does not necessarily mean that some microservices’

design principle is truly violated, which is the reason

why

KubeFreshener

enables specifying which smells

to ignore on which microservices. For instance, we

may detect that a given microservice is affected by

a wobbly service interaction, as no timeout or circuit

breaker is set in the Kubernetes deployment, but the mi-

croservices invoking it may actually implement time-

outs/circuit breakers in their source code. For future

work, we plan to enhance the support for such a kind of

situations, by integrating our methodology with other

approaches considering different inputs, e.g., (Soldani

et al., 2021) or (Pigazzini et al., 2020), to automatically

determine which architectural smells could be ignored

on which microservices.

We also plan to enhance the usability of

KubeFre-

shener

, moving from the current textual input/output

to a graphical support, e.g., displaying the application

deployment in Kubernetes, and highlighting detected

smells and refactoring templates. More broadly, we

plan to enhance the smell detection capabilities of our

methodology by supporting a wider set of architec-

tural smells, such as, e.g., those in (Carrasco et al.,

2018) or (Taibi and Lenarduzzi, 2018), or enabling

to detect other types of smells, such as, e.g., the mi-

croservices’ security smells in (Ponce et al., 2022b).

We also plan to enhance the smell resolution capabil-

ities of our methodology, by (i) supporting standards

like the Service Mesh Interface (Cloud Native Com-

puting Foundation, 2022) to generalize the refactoring

templates, (ii) fully automating the refactoring when

possible, and (iii) enabling to reason on whether to

apply a refactoring, e.g., with a trade-off analysis like

that in (Ponce et al., 2022a).

CLOSER 2023 - 13th International Conference on Cloud Computing and Services Science

ACKNOWLEDGEMENTS

This work was partly supported by the project hOlistic

Sustainable Management of distributed softWARE sys-

tems (OSMWARE, UNIPI PRA 2022 64), funded by

the University of Pisa, Italy.

REFERENCES

Arcelli, D., Cortellessa, V., and Pompeo, D. D. (2019). Au-

tomating performance antipattern detection and soft-

ware refactoring in UML models. In Wang, X. et al.,

editors, 2019 International Conference on Software

Analysis, Evolution and Reengineering, SANER 2019,

pages 639–643. IEEE Computer Society.

Balalaie, A., Heydarnoori, A., Jamshidi, P., Tamburri, D. A.,

and Lynn, T. (2018). Microservices migration pat-

terns. Software: Practice and Experience, 48(11):2019–

2042.

Carrasco, A., Bladel, B. v., and Demeyer, S. (2018). Migrat-

ing towards microservices: Migration and architecture

smells. In Ouni, A. et al., editors, Proceedings of

the 2nd International Workshop on Refactoring, IWoR

2018, pages 1–6. Association for Computing Machin-

ery.

Cloud Native Computing Foundation (2022). Service mesh

interface. https://smi-spec.io.

Fontana, F. A., Pigazzini, I., Roveda, R., Tamburri, D.,

Zanoni, M., and Di Nitto, E. (2017). Arcan: A tool

for architectural smells detection. In Malavolta, I. and

Capilla, R., editors, 2017 IEEE International Confer-

ence on Software Architecture Workshops, ICSA 2017

Workshops, pages 282–285. IEEE Computer Society.

Garcia, J., Popescu, D., Edwards, G., and Medvidovic, N.

(2009). Identifying architectural bad smells. In Winter,

A. et al., editors, Proceedings of the 2009 European

Conference on Software Maintenance and Reengineer-

ing, CSMR 2009, pages 255–258, USA. IEEE Com-

puter Society.

Haselb

ock, S., Weinreich, R., and Buchgeher, G. (2017). De-

cision models for microservices: Design areas, stake-

holders, use cases, and requirements. In Lopes, A. and

de Lemos, R., editors, Software Architecture, ECSA

2017, pages 155–170, Cham. Springer International

Publishing.

Herrera, J., Berrocal, J., Forti, S., Brogi, A., and Murilo, J.

(2023). Continuous qos-aware adaptation of cloud-iot

application placements. Computing.

Indrasiri, K. and Siriwardena, P. (2018). Microservices for

the Enterprise. Apress Berkeley, CA, 1 edition.

Istio (2022). Documentation. https://istio.io/latest/docs/.

Kubernetes (2022). Documentation. https://kubernetes.io/

docs/home/.

Neri, D., Soldani, J., Zimmermann, O., and Brogi, A. (2020).

Design principles, architectural smells and refactorings

for microservices: a multivocal review. SICS Software-

Intensive Cyber-Physical Systems, 35(1):3–15.

OASIS (2020). TOSCA Simple Proﬁle in YAML, version

1.3. OASIS Standard.

Pigazzini, I., Fontana, F. A., Lenarduzzi, V., and Taibi, D.

(2020). Towards microservice smells detection. In

Proceedings of the 3rd International Conference on

Technical Debt, TechDebt 2020, page 92–97. Associa-

tion for Computing Machinery.

Ponce, F., Soldani, J., Astudillo, H., and Brogi, A. (2022a).

Should microservice security smells stay or be refac-

tored? towards a trade-off analysis. In Gerostathopou-

los, I. et al., editors, Software Architecture, pages 131–

139, Cham. Springer International Publishing.

Ponce, F., Soldani, J., Astudillo, H., and Brogi, A. (2022b).

Smells and refactorings for microservices security: A

multivocal literature review. Journal of Systems and

Software, 192:111393.

Poulton, N. (2022). The Kubernetes Book. Independently

published, 2022 edition.

Richardson, C. (2018). Microservices Patterns. Manning

Publications, 1 edition.

Sanchez, A., Barbosa, L. S., and Madeira, A. (2015). Mod-

elling and verifying smell-free architectures with the

archery language. In Canal, C. and Idani, A., editors,

Software Engineering and Formal Methods, SEFM

2015, pages 147–163, Cham. Springer International

Publishing.

Soldani, J., Muntoni, G., Neri, D., and Brogi, A. (2021). The

TOSCA toolchain: Mining, analyzing, and refactor-

ing microservice-based architectures. Software: Prac-

tice and Experience, 51(7):1591–1621.

Soldani, J., Tamburri, D. A., and Van Den Heuvel, W.-J.

(2018). The pains and gains of microservices: A sys-

tematic grey literature review. Journal of Systems and

Software, 146:215–232.

Taibi, D. and Lenarduzzi, V. (2018). On the deﬁnition of

microservice bad smells. IEEE Software, 35(3):56–62.

Vidal, S., Vazquez, H., Diaz-Pace, J. A., Marcos, C., Garcia,

A., and Oizumi, W. (2015). JSpIRIT: A ﬂexible tool for

the analysis of code smells. In Mar

ın, B. and Soto, R.,

editors, 34th International Conference of the Chilean

Computer Science Society, SCCC 2015, pages 1–6.

IEEE Computer Society.

VMWare (2020). 3 common kubernetes security mistakes

and how to avoid them. White Paper.

Wolff, E. (2016). Microservices: Flexible Software Architec-

ture. Addison-Wesley Professional, 1 edition.

Yussupov, V., Breitenb

cher, U., Krieger, C., Leymann, F.,

Soldani, J., and Wurster, M. (2020). Pattern-based

modelling, integration, and deployment of microser-

vice architectures. In 2020 IEEE 24th International

Enterprise Distributed Object Computing Conference

(EDOC), pages 40–50. IEEE Computer Society.

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

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

Semi-Automated Smell Resolution in Kubernetes-Deployed Microservices