MICROSERVICE
COMMUNICATION DONE
RIGHT
JAVA MEETUP - VIENNA
DAMJAN GJUROVSKI 4 July 2024
Slide 3
Slide 3 text
3
HI
• Damjan Gjurovski
• Software engineer
(java), Software
architect
(microservices), Cloud
architect (GCP)
• Cover the how, the
what, the where and
the why
• Let’s talk about
practical steps on
improving microservice
systems
Slide 4
Slide 4 text
MICROSERVICE COMMUNICATION DONE RIGHT
1. How communication
patterns evolved into
microservices
2.What makes a good
microservice architecture
3.Where it all went wrong
4.Why you should not lose
all hope
Slide 5
Slide 5 text
HOW COMMUNICATION
PATTERNS EVOLVED INTO
MICROSERVICES
1
Slide 6
Slide 6 text
6
THE MYTHICAL MAN-MONTH
Slide 7
Slide 7 text
7
THE LEAN STARTUP
Slide 8
Slide 8 text
WHAT MAKES A GOOD
MICROSERVICE
ARCHITECTURE
2
Slide 9
Slide 9 text
9
SYNCHRONOUS COMMUNICATION
Slide 10
Slide 10 text
10
SERVICE DISCOVERY
Slide 11
Slide 11 text
11
LOAD BALANCING
Slide 12
Slide 12 text
12
CIRCUIT BREAKER
Slide 13
Slide 13 text
13
ASYNCHRONOUS COMMUNICATION
Slide 14
Slide 14 text
WHERE IT ALL WENT WRONG
3
Slide 15
Slide 15 text
15
TOO MUCH OF
A GOOD THING
• Services are under the
control of a single team
• Services are usually
deployed together
• The effort around
deployment and
orchestration overtakes
the effort of developing
the services
Slide 16
Slide 16 text
16
WE ARE JUST
AS IMPORTANT
AS THEY ARE
• Every team gets the
same number of
services
• Teams are very
protective of their
services
• The services don’t seem
to belong together by
any other metric aside
from belonging to the
same team
Slide 17
Slide 17 text
17
LOOKS GOOD
FROM UP HERE
• Architecture was
decided far away and
long ago
• Change is difficult and
discouraged
• Might look good on
paper but doesn’t
survive contact with
reality
Slide 18
Slide 18 text
WHY YOU SHOULD NOT LOSE
ALL HOPE
4
Slide 19
Slide 19 text
19
TOO MUCH OF
A GOOD THING
• Stabilize external
interfaces
• Consolidate
• Find the fine line and
walk it
• Automate tasks
• Do painful things more
often
Slide 20
Slide 20 text
20
WE ARE JUST
AS IMPORTANT
AS THEY ARE
• Stabilize external
interfaces
• Use contract testing to
catch changes early on
• Communicate but don’t
blame
• Defensive
programming, built-in
resiliance
Slide 21
Slide 21 text
21
LOOKS GOOD
FROM UP HERE
• Stabilize interfaces
• Communicate with
colleagues
• Observability
Slide 22
Slide 22 text
22
WANT TO KEEP THE
DISCUSSION
GOING? MESSAGE
ME ON LINKEDIN!