Performance testing

Tools and Techniques for Software Testing - Barbara Russo

SwSE - Software and Systems Engineering group

1
Modern (online) systems may
underperform as they are
overloaded
Performance testing
• Performance testing is the process of
determining the speed, responsiveness and
stability of a computer, network, software
program or device under a workload
• Performance testing can involve quantitative
tests done in a lab, or occur in the production
environment in limited scenarios
wikipedia
Open question: how to test in
in-production environments?

3
Example of performance testing:
Load Testing

Tools and Techniques for Software Testing - Barbara Russo

SwSE - Software and Systems Engineering group

4
 “Load testing is the process of
assessing the behavior of a
system under load in order to

„
detect load-related problems”
Jiang et al., 2015

Non-functional
testing
Throughput

Load Performance
Load Driver SUT
Specification Monitor

Load Intensity
What is load?

? 6
 Load

„
Amount of computational work being performed
by a software system
 Load

„
Amount of concurrent users
The Classic Load Testing Approach
… and Classic Problems

Expert Load Driver Expert/Basic Rules

LOAD SUT

Workload Specification Test Results Evaluation

The Classic Load Testing Approach
… and Classic Problems

High manual effort for maintaining load tests

Expert Load Driver Expert/Basic Rules

LOAD SUT

Workload Specification Test Results Evaluation

The Classic Load Testing Approach
… and Classic Problems

High manual effort for maintaining load tests

Expert Load Driver Expert/Basic Rules

LOAD SUT

Workload Specification Test Results Evaluation

There are no suitable load tests

The Classic Load Testing Approach
… and Classic Problems
Load tests need much time to execute
High manual effort for maintaining load tests

Expert Load Driver Expert/Basic Rules

LOAD SUT

Workload Specification Test Results Evaluation

There are no suitable load tests

The Classic Load Testing Approach
… and Classic Problems
Load tests need much time to execute
High manual effort for maintaining load tests

Expert Load Driver Expert/Basic Rules

LOAD SUT

Workload Specification Test Results Evaluation

Complex analysis of performance regressions

There are no suitable load tests
Load Testing in Continuous Delivery Pipelines
… How Problems Get Worse
Load tests need much time to execute
High manual effort for maintaining load tests

void main(String[] args) {

int foo;
main(Strin
int foo;
// do something
bar(foo); // do somet
bar(foo);
[Link](“Hi“);
}

Implementation Build Functional Testing Performance Testing

Complex analysis of performance regressions

There are no suitable load tests
Load Testing in Continuous Delivery Pipelines
… How Problems Get Worse
Load tests need much time to execute
High manual effort for maintaining load tests
void main(String[] args) {
int foo;

// do something
bar(foo);

[Link](“Hi“);
}

void main(String[] args) {

int foo;
main(Strin
int foo;
// do something
bar(foo); // do somet
bar(foo);
[Link](“Hi“);
}

Implementation Build Functional Testing Performance Testing

void main(String[] args) {

int foo;

// do something
bar(foo);

[Link](“Hi“);
}

Complex analysis of performance regressions

There are no suitable load tests
Load Testing in Continuous Delivery Pipelines
… How Problems Get Worse
Load tests need much time to execute
vs.
High manual effort for maintaining load tests
Fast & frequent releases
void main(String[] args) {
int foo;

// do something
bar(foo);

[Link](“Hi“);
}

void main(String[] args) {

int foo;
main(Strin
int foo;
// do something
bar(foo); // do somet
bar(foo);
[Link](“Hi“);
}

Implementation Build Functional Testing Performance Testing

void main(String[] args) {

int foo;

// do something
bar(foo);

[Link](“Hi“);
}

Complex analysis of performance regressions

There are no suitable load tests
Load Testing in Continuous Delivery Pipelines
… How Problems Get Worse
Load tests need much time to execute
vs.
High manual effort for maintaining load tests
Fast & frequent releases
vs.
Pipeline automation
void main(String[] args) {
int foo;

// do something
bar(foo);

[Link](“Hi“);
}

void main(String[] args) {

int foo;
main(Strin
int foo;
// do something
bar(foo); // do somet
bar(foo);
[Link](“Hi“);
}

Implementation Build Functional Testing Performance Testing

void main(String[] args) {

int foo;

// do something
bar(foo);

[Link](“Hi“);
}

Complex analysis of performance regressions

There are no suitable load tests
Load Testing in Continuous Delivery Pipelines
… How Problems Get Worse
Load tests need much time to execute
vs.
High manual effort for maintaining load tests
Fast & frequent releases
vs.
Pipeline automation
void main(String[] args) {
int foo;

// do something
bar(foo);

[Link](“Hi“);
}

void main(String[] args) {

int foo;
main(Strin
int foo;
// do something
bar(foo); // do somet
bar(foo);
[Link](“Hi“);
}

Implementation Build Functional Testing Performance Testing

void main(String[] args) {

int foo;

// do something
bar(foo);

[Link](“Hi“);
}

Service-focus requires multiple tests

vs. Complex analysis of performance regressions
There are no suitable load tests
Load Testing in Continuous Delivery Pipelines
… How Problems Get Worse
Load tests need much time to execute
vs.
High manual effort for maintaining load tests
Fast & frequent releases
vs.
Pipeline automation
void main(String[] args) {
int foo;

// do something
bar(foo);

[Link](“Hi“);
}

void main(String[] args) {

int foo;
main(Strin
int foo;
// do something
bar(foo); // do somet
bar(foo);
[Link](“Hi“);
}

Implementation Build Functional Testing Performance Testing

void main(String[] args) {

int foo;

// do something
bar(foo);

[Link](“Hi“);
}

Complex load tests for every release impossible

Service-focus requires multiple tests vs.
vs. Complex analysis of performance regressions
There are no suitable load tests
Workload specification
• The workload specification Model consists of:
• An Application Model, specifying allowed sequences of service
invocations and SUT-specific details for generating valid requests
• A set of Behavior Models, each providing a probabilistic
representation of user sessions in terms of invoked services and
think times between subsequent invocations as Markov Chains
• A Behavior Mix, specified as probabilities (frequencies) for the
individual Behavior Models to occur during workload generation
• A Workload Intensity that includes a function which specifies the
(possibly varying) number of concurrent users during the workload
generation execution

10
A tool to design and execute load
tests and detect any performance
degradation in pipelines of in-
production systems
Monitoring data
• Loads frequencies, Request logs, traces, and
response times of the service interfaces
• The data is enriched by various contextual
information, e.g., marketing campaigns,
public holidays, or sports events

12
ContinuITy
Load Test Generation & Execution
ContinuITy
Load Test Generation & Execution

Henning Schulz, Tobias Angerstein, and André van Hoorn:

Towards automating representative load testing in continuous
software engineering.

In Proceedings of the ACM/SPEC International Conference on

Performance Engineering (ICPE 2018) Companion (7th International
Workshop on Load Testing and Benchmarking of Software Systems, LTB
2018), pages 123–126. ACM, 2018
ContinuITy
Load Test Generation & Execution

Monitoring Data

Workload Model
Evolution

Henning Schulz, Tobias Angerstein, and André van Hoorn:

Towards automating representative load testing in continuous
software engineering.

In Proceedings of the ACM/SPEC International Conference on

Performance Engineering (ICPE 2018) Companion (7th International
Workshop on Load Testing and Benchmarking of Software Systems, LTB
2018), pages 123–126. ACM, 2018
ContinuITy
Load Test Generation & Execution

Monitoring Data

Workload Model
Evolution

Henning Schulz, Tobias Angerstein, and André van Hoorn:

Towards automating representative load testing in continuous
software engineering.

In Proceedings of the ACM/SPEC International Conference on

Performance Engineering (ICPE 2018) Companion (7th International
Workshop on Load Testing and Benchmarking of Software Systems, LTB
2018), pages 123–126. ACM, 2018
ContinuITy
Load Test Generation & Execution Contextual
Information

Monitoring Data

Workload Model
Evolution

Henning Schulz, Tobias Angerstein, and André van Hoorn:

Towards automating representative load testing in continuous
software engineering.

In Proceedings of the ACM/SPEC International Conference on

Performance Engineering (ICPE 2018) Companion (7th International
Workshop on Load Testing and Benchmarking of Software Systems, LTB
2018), pages 123–126. ACM, 2018
ContinuITy
Load Test Generation & Execution Contextual
Information

Monitoring Data

Workload Model Workload Model

Evolution Selection

Henning Schulz, Tobias Angerstein, and André van Hoorn:

Towards automating representative load testing in continuous
software engineering.

In Proceedings of the ACM/SPEC International Conference on

Performance Engineering (ICPE 2018) Companion (7th International
Workshop on Load Testing and Benchmarking of Software Systems, LTB
2018), pages 123–126. ACM, 2018
ContinuITy
Load Test Generation & Execution Contextual
Information

Automated
Monitoring Data
Execution

Workload Model Workload Model Test Result

Evolution Selection

Henning Schulz, Tobias Angerstein, and André van Hoorn:

Towards automating representative load testing in continuous
software engineering.

In Proceedings of the ACM/SPEC International Conference on

Performance Engineering (ICPE 2018) Companion (7th International
Workshop on Load Testing and Benchmarking of Software Systems, LTB
2018), pages 123–126. ACM, 2018
Load test automation

Tools and Techniques for Software Testing - Barbara Russo

SwSE - Software and Systems Engineering group

14
What is it for?
• Identify deployment configuration(s) for which
the system performs best for all workloads
• Characterize systems‘ resilience over workload
• Analyse individual service failure or
degradation
• Reveal attacks
• Monitor the performance in a transition to
microservices

15
 PPTAM
Production and Performance Testing-Based Application Monitoring

0 1 2 3 4
C ec i f A a i f E ei e E ei e D ai e ic
Se

e a i a da a eai a da a ge e a i e ec i ca c a i
E i ica di ib i f Ba e i e & e e D ai e ic
O eai a e
ad i a i e a chi ec a c g. da hb a d
(I e edia e)

f' i 0
...
­1
0.25

...

...

...

...

...
300 x
A ifac

0.015 2.164 0.20

1 x
...
0.2 0.042 0.108 x x

#W ad
x

Re a i e Ma
A chi ec .
0.15 x
a /fail (c ) PASS FAIL
x
1.26 % 2.58 % 100.00 % 0.10

i ai c g. ⋅c
m. e ma
1.26 %
(^ i * '( '))
0.00 % 74.81 %
0.142
0.05 x x

t
0 x x

...

...

...

...

...
9 AM 100 200 300
λ'
50 100 150 200 250 300
W k ad Si a i (N be fU e )

a ­c ck i e am led kl ad i a i

L ad e
e ae Be chF
T

C i IT Faba
 What it does?
• It collects the operational profile of a microservice system
• It automatically runs a series of experiments with given usage
profiles and probability of use (R scripts)
• It runs experiments according to templates that control time, number of
agents, and single operation max response (Faban)
• It sets the goals of testing (e.g., resource config) and collects data
for each experiment or multi-experiment (Benchflow)
• It identifies failing services (baseline threshold R scripts)
• It computes a total metric of performance on non-failing services for
each system configuration (CPU, memory, replicas) over workloads (via R
scripts)
• It visualizes into interactive graphs (R shop, R shiny, and R plottly)

17
Avritzer and Russo: Operational Profile Data for Continuous Dependability Assessment in DevOps
What it does
0 1
C ec i f A a i f

Se
• Collects the e a i a da a eai a da a

operational data of O eai a e

E

(I e edia e)
systems 300
f'

A ifac
0.2
#W ad
• Builds the operational 9 AM t
i ai

profile a ­c ck i e
0.07
0.06
0.05
frequency

0.04

T
0.03
0.02
0.01
0.00

50 100 150 200 250 300

Workload situation (number of users)

 What it does0 1 2 3
C ec i f A a i f E ei e E ei e
Se

e a i a da a eai a da a ge e a i e ec i
• Automatically
O eai a e
runs a E i ica di ib i f Ba
ad i a i e
series of experiments
(I e edia e)

f' i

...
300

with given usage

A ifac

1
0.2
#W ad A chi ec . a

i ai
profiles andt c g. ⋅
m

...
9 AM 100 200 300
a ­c ck i e am led kl ad i a i
λ'
probability of use
L ad e
e ae Be chF
T

C i IT Faba
BenchFlow Automation Framework

Generation
20
BenchFlow Automation Framework

Generation
Test Generation

20
BenchFlow Automation Framework
Test Bundle

Generation
Test Generation

20
BenchFlow Automation Framework
Test Bundle

Generation
Experiment Bundle

Test Generation Experiment Generation

20
BenchFlow Automation Framework
Test Bundle

Generation
Experiment Bundle

Test Generation Experiment Generation

Execution
Experiment Execution

20
BenchFlow Automation Framework
Test Bundle

Generation
Experiment Bundle

Test Generation Experiment Generation

Execution
Failures

Success Experiment Execution

20
BenchFlow Automation Framework
Test Bundle

Generation
Experiment Bundle

Test Generation Experiment Generation

Execution
Failures

Success Experiment Execution

Analysis
Result Analysis

20
BenchFlow Automation Framework
Test Bundle

Generation
Experiment Bundle

Test Generation Experiment Generation

Execution
Failures

Metrics
Success Experiment Execution

Analysis
Result Analysis

20
Experiment execution design
(faban)
• Usage profiles ([Link])

• Configuration [Link]
<!-- The rampup, steadystate, and rampdown of the driver -->
<fa:runControl unit="time">
<fa:rampUp>60</fa:rampUp>
<fa:steadyState>1800</fa:steadyState> <!-- The number of agents, or host:agents pairs
<fa:rampDown>0</fa:rampDown> separated by space -->
</fa:runControl> <agents>10</agents>

21
 What it does
2 3 4
A a i f E ei e E ei e D ai e ic
eai a da a ge e a i e ec i ca c a i
• Service
E i ica failures
di ib i f over Ba e i e & e e D ai e ic

time
ad i a i e a chi ec a c g. da hb a d
f' i 0
...
­1
0.25

...

...

...

...

...
x

0.015 2.164 0.20

• Total performance of
1 x
...
0.2 0.042 0.108 x x

#W ad
x

Re a i e Ma
A chi ec .
0.15 x
a /fail (c ) PASS FAIL
x
1.26 % 2.58 % 100.00 % 0.10

i ai c g. ⋅c 1.26 % 0.00 % 74.81 %

0.05 x x

system in use λ'

m. e ma (^ i * '( ')) 0.142
0 x x

...

...

...

...

...
100 200 300 50 100 150
W k ad Si a i (N
200
be
250
fU e )
300

am led kl ad i a i

• Per (micro)service
performance
L ad e time series
Be chF
e ae

• Performance
degradation
C i IT under an
Faba

attack
[Link]
[Link]

Total system
performance - under
different sys resources
[Link]

Service
failure

Total system
performance - under
different sys resources
No attack
[Link]

Service
failure
failures

Total system
performance - under
different sys resources
Under
No attack attack
 Cockpit
Monitoring cockpit
[Link]

24
Case studies

Tools and Techniques for Software Testing - Barbara Russo

SwSE - Software and Systems Engineering group

25
Microservice architecture
• In a microservice architecture, services are
fine-grained and the protocols are lightweight
rendering each micro service loosely coupled
with the others
• Microservice architectures often use containers
to enforce service independence

26
Before starting a transition …
• There are characteristics that are shared by microservice
architectures:
• Data is organized in a decentralized way: each service
manages its own data makes it independently
deployable Data independently
deployable

• Teams that build systems with microservices

extensively use infrastructure automation techniques
(like continuous integration or continuous delivery)

Automation

27
Quantitative Assessment of
Deployment Alternatives
• Challenge: assess performance of
architectural deployment alternatives
(e.g., number of replicas, CPU/memory
allocation, technology stack) under fuzzy
requirements
Alberto Avritzer, Vincenzo Ferme, Andrea Janes, Barbara Russo,
Henning Schulz, and André van Hoorn:
A Quantitative Approach for the Assessment of
Microservice Architecture Deployment
Alternatives by Automated Performance Testing.

In Proceedings of the 12th European Conference on Software

Architecture (ECSA). LNCS, Springer, 2018 (Accepted)

28
Quantitative Assessment of
Deployment Alternatives
• Approach
• Use operational data to generate and weigh load
tests
• Measure baseline requirements
• Design a metric that allows quantitative
comparison of deployment alternatives

29
Overview of Approach

Production

30
Overview of Approach

Load Level
Time

Production Observed load situations

30
Overview of Approach
1

Rel. Freq.
Load Level
Time Load intensity

Production Observed load situations Empirical distribution of load situations

30
Overview of Approach
1

Rel. Freq.
Load Level
Time Load intensity

Production Observed load situations Empirical distribution of load situations

Aggr. Rel. Freq.

Sampled load intensities
Empirical Distribution of Load situations

Sampled load tests

30
Overview of Approach
1

Rel. Freq.
Load Level
Time Load intensity

Production Observed load situations Empirical distribution of load situations

3 2
0.12 0.14 0.20 0.16 0.11

Aggr. Rel. Freq.

Test results
Scalability criteria
Sampled load intensities
Baseline test Empirical Distribution of Load situations

Deployment conf. Sampled load tests

30
Overview of Approach
1

Rel. Freq.
Load Level
Time Load intensity

Production Observed load situations Empirical distribution of load situations

3 2
0.12 0.14 0.20 0.16 0.11

Aggr. Rel. Freq.

0.73 Test results
Scalability criteria
Sampled load intensities
Baseline test Empirical Distribution of Load situations

4
Domain Metric Deployment conf. Sampled load tests

30
System Under Test
 Experiments

12 microservices

Production

Avritzer and Russo: Operational Profile Data for Continuous Dependability Assessment in DevOps 32
 Experiments

1,2
12 microservices 6 Load Levels

50,100,150,200,250,300
Workload intensities

Production Empirical Distribution of Load intensities

Sampled Load Tests

Custom Op. Mix

Avritzer and Russo: Operational Profile Data for Continuous Dependability Assessment in DevOps 32
 Experiments

1,2 3
12 microservices 6 Load Levels 12 configurations

RAM CPU
50,100,150,200,250,300
Workload intensities Replicas

Production Empirical Distribution of Load intensities

Deployment Config.
Sampled Load Tests Scal = avg + 3σ
Custom Op. Mix

Avritzer and Russo: Operational Profile Data for Continuous Dependability Assessment in DevOps 32
Experiment Results: Computation
of Domain Metric (1/2)

Users Aggr. Rel. Freq.

Scalability 50 0.10582
API
Criteria 100 0.18519
GET / PASS 150 0.22222
GET /cart PASS 200 0.22222
250 0.20370
POST /item FAIL
300 0.06085

Custom Op. Mix Aggr. Rel. Freq. Contrib. to Domain Metric

Deployment Configuration: 1 GB RAM, 0.25 CPU, 1 Replica

33
Experiment Results: Computation
of Domain Metric (1/2)

Users Aggr. Rel. Freq.

Scalability 50 0.10582
API
Criteria 100 0.18519 Max: 0.20370
GET / PASS 150 0.22222
GET /cart PASS 200 0.22222
Actual: 0.13580
250 0.20370
POST /item FAIL
300 0.06085

Custom Op. Mix Aggr. Rel. Freq. Contrib. to Domain Metric

Deployment Configuration: 1 GB RAM, 0.25 CPU, 1 Replica

33
Experiment Results: Computation
of Domain Metric (2/2)
Users Contribution

50 0.10582
100 0.18519
150 0.22222
200 0.07999
250 0.13580
300 0.04729

Contrib. to Domain Metric

Deployment Configuration: 1 GB RAM, 0.25 CPU, 1 Replica

34
Experiment Results: Computation
of Domain Metric (2/2)
Users Contribution
Max: 1
50 0.10582
100 0.18519
150 0.22222
200 0.07999
250 0.13580
300 0.04729
4
Contrib. to Domain Metric Domain Metric

Deployment Configuration: 1 GB RAM, 0.25 CPU, 1 Replica

34
Experiment Results: Computation
of Domain Metric (2/2)
Users Contribution
Max: 1
50 0.10582
100 0.18519
150 0.22222 Actual:
200 0.07999
250 0.13580 0.77631
300 0.04729
4
Contrib. to Domain Metric Domain Metric

Deployment Configuration: 1 GB RAM, 0.25 CPU, 1 Replica

34
Experiment Results: Single-Metric
Comparison of Alternatives

35
Experiment Results: Single-Metric
Comparison of Alternatives

35
Experiment Results: Single-Metric
Comparison of Alternatives

35
Experiment Results: Visual
Comparison of Alternatives
Contrib. to Domain Metric

Sampled Load Tests

36
Experiment Results: Visual
Comparison of Alternatives
Max Contrib.
Contrib. to Domain Metric

Sampled Load Tests

36
Experiment Results: Visual
Comparison of Alternatives
Max Contrib.
Contrib. to Domain Metric

Depl. Conf.

Sampled Load Tests

36
Extensions/Application

37
Extensions/Application
• We have tested it on an online demo-platform
• We have extended it to monitor performce
degradation under attacks by incorporating
Mirai

37
Extensions/Application
• We have tested it on an online demo-platform
• We have extended it to monitor performce
degradation under attacks by incorporating
Mirai
• We have designed it for monitoring
performance degradation during a transition to
microservices

37
38
Bare-metal versus
virtualization
environment

38
System Under Test
Experiment settings
• 2 VM one for SUT and one for Test
• SUT: docker containers each for on micro
service, one for DB
Bare-metal
• The containerized bare metal machines:
• Load driver server - 32 GB RAM, 24 cores (2
threads each) at 2300 MHz and SUT server - 896
GB RAM, 80 cores (2 threads each) at 2300
MHz
• Both machines use magnetic disks with 15 000
rpm and are connected using a shared 10 Gbit/ s
network infrastructure

41
Virtual
• The containerized deployment in virtual machines:
• Load driver server - 4 GB RAM, 1 core at 2600MHz
and SUT server - 8 GB RAM, 4 cores at 2600 MHz
with SSDs
• Both machines use an EMCVNC 5400 series network
attached storage solution12 and are connected using a
shared 10 Gbit/ s network infrastructure

• We replicated with SUT server - 16 GB RAM, 8 cores

42
 Experiments - results
Virtual Bare metal

Virtual more resources

for SUT

43
 Experiments - results
Virtual Bare metal

Virtual more resources

for SUT

43
Bare-metal versus
virtualization
environment

44
Bare-metal versus
Monitor performance
virtualization
degradation under
environment
attacks

44
System Under Test
Mirai BotNet
• Mirai is a malware that has been used to turn
networked devices (cameras) running Linux into
remotely controlled bots

• We use an academic version of it to attack the system

in controlled experiments

• It can perform different types of attack. By now, we

have explored http, syn, ack

46
Experiments with Mirai
• Attack with simple http requests (GET and
POST to home - increase the load)

• Compute the metric with and without attack to

understand:
• the resilience of a system
• the early prediction of an attack

47
 PPTAM Mirai

0 1 2 3 4
C ec i f A a i f E ei e E ei e D ai e ic
Se

e a i a da a eai a da a ge e a i e ec i ca c a i
E i ica di ib i f Ba e i e & e e D ai e ic
O eai a e
ad i a i e a chi ec a c g. da hb a d
(I e edia e)

f' i 0
...
­1
0.25

...

...

...

...

...
300 x
A ifac

0.015 2.164 0.20

1 x
...
0.2 0.042 0.108 x x

#W ad
x

Re a i e Ma
A chi ec .
0.15 x
a /fail (c ) PASS FAIL
x
1.26 % 2.58 % 100.00 % 0.10

i ai c g. ⋅c
m. e ma
1.26 %
(^ i * '( '))
0.00 % 74.81 %
0.142
0.05 x x

t
0 x x

...

...

...

...

...
9 AM 100 200 300
λ'
50 100 150 200 250 300
W k ad Si a i (N be fU e )

a ­c ck i e am led kl ad i a i

L ad e
e ae Be chF
T

C i IT Faba

48
Experiments - results
Virtual – no attack Virtual - attack

49
Attack design
• After few piloting attacks (5-10-20 mins)

• Duration of attack: 20 minutes (1200 seconds);

• Protocol used: HTTP;
• IP address to attack: the IP address of the SUT, i.e.,
the
• Machine with Sock Shop installed;
• Number of threads: 256.

50
Bare-metal versus
virtualization Monitor performance
environment degradation under
attacks

51
Bare-metal versus
virtualization Monitor performance
environment degradation under
attacks

Monitoring
performance
degradation during a
transition to
microservices

51
Dehghani’s approach to transition
• Identify one capability in the monolith to
transform it into microservice(s)

52
Dehghani’s approach to transition
• Decouple it from the monolith into an external
service
• Maintain the old monolith with all its existing
functionalities
• Work incrementally: build, test, and deploy

Z. Dehghani, “How to break a Monolith into Microservices,” April 2018, Fowler’s page

53
Transition uncertainty
• Some aspects are new:
• one has to decide on a communication
infrastructure
• Other aspects that are valid when developing a
monolith have to be reconsidered
• For instance, how to keep communication
between services minimal (as communication is
costly and might impede scalability)

54
Transition uncertainty
• It requires the team to acquire new
knowledge and to learn how to apply it
• New software design patterns for microservice
architectures:
• API Gateway pattern to organize how clients
can access individual services

F. Pacheco, Microservice Patterns and Best Practices: Explore Patterns Like CQRS and
Event Sourcing to Create Scalable, Maintainable, and Testable Microservices, Packt
Publishing, 2018

55
Transition uncertainty
• A transition to microservices may or may not
end up with the same or better performing
system

• It depends on the ability of the developers to

design microservices and the capability of the
microservices architecture to represent the
system

56
Main steps

57
Main steps
• Compute the operational profile of a monolith
• Apply PPTAM to collect individual service -
individual experiment - individual workload
time series
• Monitoring performance degradation over
time against baseline and experiments’
average performance

57
Main steps
• Compute the operational profile of a monolith
• Apply PPTAM to collect individual service -
individual experiment - individual workload
time series
• Monitoring performance degradation over
time against baseline and experiments’
average performance
• Analytic extension: visualize such analysis (R
shiny)

57
58
Application to a transition
• If the new architecture performs under a
given threshold, developers stop and
rethink of the architecture or rethink the
used patterns to guarantee that the new
system - while having all advantages of a
microservice architecture - does not fall
short in terms of performance

59