Remember the good old days, when a user would report a possible bug, and you were able to quickly reproduce it on your laptop? Remember when a well-factored application would keep its core business logic in small and testable objects? Remember when you could run your application inside the IDE, with a rich debugger and step through every single line? Remember when running 90% worth of test coverage took 5 minutes and didn't have to spin up any infrastructure? As much as cloud-native applications and microservices help us be more productive, resilient, and grow to unprecedented scales, they also bring an entirely new class of challenges. Highly-distributed applications can be harder to monitor and debug, the bug you are looking for is in one of the many, many moving pieces that collaborate to implement a feature. In this talk, let's explore how the challenge of debugging applications has changed in a highly-distributed world. Let's talk about how the pioneering microservices architectures used to deal with it, and how these initial bespoke strategies have evolved into cloud-native infrastructure components such as Kubernetes and a service mesh. About Phil: Phil Calçado is an engineer at Buoyant, working on Conduit and Linkerd, the pioneering open-source service mesh software used by everyone from small startups to Fortune 100 companies. Before Buoyant, he was the Director of Engineering at DigitalOcean, leading the microservices adoption that now powers the cloud provider. Phil is known as a pioneer in microservices, as he headed the teams that built SoundCloud's microservices architecture and their product engineering organisation. From: https://www.meetup.com/microservices-apis-integration-meetup/events/248003611/

1. Debugging
Microservices
Phil Calçado
h6p://philcalcado.com
@pcalcado

3. The story so far…

4. Your typical architecture circa 2001

5. As business become more tech-aware…

6. AIer dropping the users table for the 5th Kme…

7. And we kept breaking them down…

8. Debugging
Mono and Microliths

9. One way to go about it

10. 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

11. 5. Run all tests ?

12. Debugging
Microservices

13. 1. Find the relevant “virtual circuit”

14. 2. Bring up the right components

15. 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

16. But the whole is
greater than the
sum of its parts.

18. The plaYorm ma6ers

20. So how do we go about it?

21. OpKon 1) Observability

22. Sorry, that’s
all I had.
!

23. Observability circa
2010

24. AlerKng
Timeouts
This is your code on microservices
Biz Logic
Timeouts
Telemetry
…
AuthorizaKon
Client-side
Service Discovery

25. ~25% of engineering
Kme was dealing with
cross-cucng aspects

26. Observability circa
2016

27. Each service has a manifest

29. ~10 engineers
working on tooling
full-Kme

30. required a
standardized
development stack

31. Observability these
days

32. A lot of this is available at the network level

33. • 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

34. We need a smart
network that
leverages this data.

38. h6p://philcalcado.com/2017/08/03/pa6ern_service_mesh.html

39. OpKon 1) Service
Proxy

41. OpKon 2) Sidecars

43. Early 2010s => ad-hoc code
Mid 2010s => smart build pipelines
Late 2010s => smart networks

44. Debuggability and simplicity
aren’t reasons to adopt
microservices

45. Q&A