Managing dozens or hundreds of microservices in scale and feel blind to how a new version might affect production? What if we could predict the behavior in production and anticipate issues during development just by observing on API communication? In this talk, he will introduce a new method to collect and analyze API communication from production and how to leverage this data during development & testing phases to improve our code. By relying on production behavior we can automatically generate API tests that are more efficient, catch dependencies that are about to break in real-life and to have our developers more product & production oriented.

1. Hundreds of Microservices
Without Breaking Your APIs
Michael Haberman
CTO @ Aspecto

2. Agenda
● Microservices are complex by definition
○ A journey of microservices
● Tool available to handle the complexity
● Tasks which theren’t mature tool yet

3. About me
● Managed ~120 microservice in high scale
● Many project of monolith to microservices
● After ~5 years my own startup at that area -> aspecto.io

4. The start of microservice journey
Service A Service B Service C
DBDB DB

5. The start of microservice journey
Service A Service B Service C
DBDB DB
HTTP HTTP
HTTP

6. ● Three services (one db server, multiple tables)
● Running locally is still simple
● Remember the whole architecture is doable
● Onboarding a new developer is straightforward
The start of microservice journey

7. Few month later
Service
A
Service
B
Service
C
DBDB DB
Service
D
Service
E
Service
F
DBDB DB
Service
G
Service
H
Service
I
DBDB DB
Service
J
Service
K
Service
L
DBDB DB

8. ● Hard to see the whole picture
● Hard to know to payload / structure between services
● Running it locally is a challenge
Problems start to arise
As the picture gets bigger, the risk
of breaking change increases

9. ● Hard to see the whole picture
○ Let’s do a architecture document
● Hard to know to payload / structure between services
○ Swagger documentation
● Running it locally is a challenge
○ Dev environment
Let’s solve it!
Local env with one
service
Other services in
cloud

10. ● Your first downtime…
● You learn that HTTP is good when the entire environment is up and running
● But when there are services unavailable you have data lose
Alert!

11. Your boss is mad :/

12. Lets fix it

13. ● So HTTP isn’t scalable enough for your.
● Let’s move to async communication
○ Pub/Sub
○ Distributed Queue
○ Kafka
How to fix is

14. The start of microservice journey
Service A Service B Service C
DBDB DB
Kafka
Kafka
Kafka

15. ● Our data is now persistent!
● We are experienced enough in microservices, what are the downsides?
No more data lose

16. ● Swagger isn’t relevant anymore, how to visualize communication?
● How to run it locally? We need to have env per developer?!
● How to debug a service which gets data from another source (can’t send a API
request via postman)
● The whole picture got way more complicated
Downsides for async?

17. Downsides for async?
My local
Shared kafka
peer local
Cloud version
Who will consume the message?

18. ● Swagger isn’t relevant anymore, how to visualize communication?
● How to run it locally? We need to have env per developer?!
● How to debug a service which gets data from another source (can’t send a API
request via postman)
● The whole picture got way more complicated
Downsides for async?

19. Downsides for async?
My local
Shared kafka
peer local
Cloud version
How to produce a message?

20. Service
A
Service
B
Service
C
DBDB DB
Service
D
Service
E
Service
F
DBDB DB
Service
G
Service
H
Service
I
DBDB DB
Service
J
Service
K
Service
L
DBDB DB
Kafka
Kafka
Kafka
Kafka
Kafka
Kafka

21. Bigger picture == High risk
Serving the developer with the bigger picture will reduce the risk

22. ● How it works:
○ Library within the code
○ Collects distributed tracing
○ Report to central server
Tracing for the win!

23. Tracing for the win!
● It helps with:
○ Visuale
○ Debug (trace id)
○ Understand the big picture
● Won’t help with:
○ Local dev
○ Test
○ Reproduce an issue

24. ● Moved to Async communication
● Can see all the traces
○ No need in architecture diagram
● We don’t have swagger replacement
● Hard to know what to test
Our journey

25. ● Micro services - small, one responsibility -> a lot of them
● The right tool for the job, programming language, db
● Not only HTTP, async communication
The basic roles that makes microservice complicated

26. Thanks you!
michael@aspecto.io