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