Debugging MicroservicesPhil Calçado h6p://philcalcado.com @pcalcado
The story so far…
Your typical architecture circa 2001
As business become more tech-aware…
AIer dropping the users table for the 5th Kme…
And we kept breaking them down…
Debugging Mono and Microliths
One way to go about it
1.Write a new test with the reproducKon steps
2.See that test fail 3.Change the code to fix it 4.See that test pass 5.Run all unit tests
My favorite way to go about it
5. Run all tests?
Debugging Microservices
1. Find the relevant “virtual circuit”
2. Bring up the right components
1.Write a new test with the reproducKon steps
2.See that test fail 3.Change the code to fix it 4.See that test pass 5.Run all unit tests
3. Test
But the whole is greater than the sum of its parts.
The plaYorm ma6ers
So how do we go about it?
OpKon 1) Observability
Sorry, that’s all I had.
!
Observability circa 2010
AlerKngTimeouts
This is your code on microservices
Biz Logic
Timeouts
Telemetry
…
AuthorizaKon
Client-side Service Discovery
~25% of engineering Kme was dealing with cross-cucng aspects
Observability circa 2016
Each service has a manifest
~10 engineers working on tooling
full-Kme
required a standardized
development stack
Observability these days
A lot of this is available at the network level
• Who you are • Where you are located geographically • Who you need to talk to • Your average availability • Your security constraints • …
A lot of this is already available to the infrastructure
We need a smart network that
leverages this data.
h6p://philcalcado.com/2017/08/03/pa6ern_service_mesh.html
OpKon 1) Service Proxy
OpKon 2) Sidecars
Early 2010s => ad-hoc code
Mid 2010s => smart build pipelines
Late 2010s => smart networks
Debuggability and simplicity aren’t reasons to adopt
microservices
Q&A