The document discusses the challenges of debugging microservices and the development/test loop in Kubernetes, highlighting the increasing complexity as the number of services grows. It introduces tools like mocks, service virtualization, and telepresence that assist in remote-to-local development to mitigate these challenges. The conclusion emphasizes selecting the right dev/test approach based on the project requirements.

1. Debugging Microservices "Remocally" in
Kubernetes with Telepresence
Daniel Bryant
@danielbryantuk

2. @danielbryantuk
tl;dr
2
• The inner dev/test loop can be painful with microservices & Kubernetes
• The pain increases as the number of services within your system increase
• You have options with +/- : mocks, service virtualisation, remocal tools
• Telepresence enables remote-to-local “remocal” development
• Choose your dev/test approach wisely!

3. @danielbryantuk
3

4. Setting the Scene
4

5. @danielbryantuk
Inner and outer dev loops
5
Hat tip to Mitch Denny (now 404): https://mitchdenny.com/the-inner-loop/
http://jorgemoral.es/posts/2020_03_17-develop_apps…

6. @danielbryantuk
You are building microservices, right?
6

7. @danielbryantuk
SOA: There’s just more stu
ff
(and dependencies)
7

8. @danielbryantuk
So, let’s run everything locally…
8

9. @danielbryantuk
tl;dr
9
“My laptop only has 16GB
RAM and you’re asking it
to run Kubernetes and a
JVM and a database???”

10. @danielbryantuk
Okay, let’s run everything remotely…
10

11. @danielbryantuk
Inner and outer dev loops with K8s
can be the same
11
• Write code
• Build container
• Push to registry
• Deploy to cluster
• Test
And can be …. SLOW.

12. @danielbryantuk
Automation can help…
12

13. @danielbryantuk
tl;dr
13
But you want a really fast inner loop (no docker build/push) …

14. @danielbryantuk
tl;dr
14 And you want to use your own tools.

15. @danielbryantuk
tl;dr
15
And you want to avoid the “works on my machine”
production vs local dev debacle

16. Options and Tradeo
ff
s
16

17. @danielbryantuk
What are your options?
17
• Mocks
• Mockito, PowerMock(ito), EasyMock, JMockit
• Service virtualisation
• TestContainers
• Hoverfly, WireMock
• Remocal tooling
• Telepresence
• Devspaces, Okteto

18. @danielbryantuk
Mocks
18
https://site.mockito.org/

19. @danielbryantuk
Mocks
19
• Good
• Idiomatic (familiar language constructs etc)
• Quick and cheap
• Can help build your mental model (TDD-like)
• Bad
• Implicit assumptions coded in (“the three realities conundrum”)
• Di
ff
icult to keep up to date and share/coordinate
• Needs a test runner

20. @danielbryantuk
Service virtualisation
20
https://livebook.manning.com/book/testing-java-microservices/chapter-9/47

21. @danielbryantuk
Service virtualisation
21
https://livebook.manning.com/book/testing-java-microservices/chapter-9/47

22. @danielbryantuk
TestContainers
22

23. @danielbryantuk
Service virtualisation
23
• Good
• More realistic than mocks (can be the “real thing”, albeit resource constrained)
• Enables (wire-level) deterministic test of failure scenarios
• Easy to use large(r) amounts of data
• Bad
• Slower than mocks to initialise
• Can be tricky to configure
• Challenging to keep up to date and share (unless you use dedicated tooling/SaaS)

24. @danielbryantuk
Remocal tooling
24

25. @danielbryantuk
Remocal tooling
25
• Good
• Enables testing against (and poking of) the real thing
• Data sets can be large scale (as resources can be scaled on remote cluster)
• No need to build mental model of dependency (both good and bad!)
• Bad
• Need a solid network connection
• Mutating remote shared state can be an issue
• Lack of language bindings

26. @danielbryantuk
26

27. @danielbryantuk
What is Telepresence
27
• “Fancy Kubernetes VPN for development”
• “kubectl port-forward on steroids”
• “kubectl proxy all-the-things”
• A network bridge between your laptop and the Kubernetes cluster

28. @danielbryantuk
Telepresence: Local-to-Remote bridge
28

29. @danielbryantuk
Telepresence: Local-to-Remote bridge
29
www.youtube.com/watch?v=W_a3aErN3NU

30. Demo Time!
30

31. @danielbryantuk
Telepresence: Local-to-Remote bridge
31
telepresence connect
• Open a tunnel to the remote cluster; exposes “in-cluster” services/network/DNS
telepresence intercept my-service —port 3000
• Re-routes (intercepts) tra
ff
ic to my-service in the remote cluster to my local machine
telepresence login & telepresence intercept
• Create preview URL to isolate and share results of the intercept

32. @danielbryantuk
Telepresence: Local-to-Remote bridge
$ telepresence intercept dataprocessingnodeservice --port 3000
32
Using deployment dataprocessingnodeservice
intercepted
State : ACTIVE
Destination : 127.0.0.1:3000
Intercepting: HTTP requests that match all of:
header("x-telepresence-intercept-id") ~= regexp ("76a1e848-1829-74x-1138-e3294c1e9119:dataprocessingnodeservice")
Preview URL : https://[random-subdomain].preview.edgestack.me
www.youtube.com/watch?v=W_a3aErN3NU

33. @danielbryantuk
Preview URLs, Personal Intercepts
33

34. Docker Desktop Extension for Telepresence
34
getambassador.io/testing-with-telepresence-and-docker

35. 35

36. Wrapping up
36

37. @danielbryantuk
Testing Microservices: What to use, when
37
Mocks Service virtualization Remocal
Unit tests ✅
Integration tests ✅ ✅
Component tests ✅ ✅ ✅
End-to-end tests ✅ ✅
Poking around an
existing API
✅
Building an API ✅ ✅

38. @danielbryantuk
Conclusion
38
• The inner dev/test loop can be painful with microservices & Kubernetes
• The pain increases as the number of services within your system increase
• You have options with +/- : mocks, service virtualisation, remocal tools
• Telepresence enables remote-to-local “remocal” development
• Choose your dev/test approach wisely!

39. @danielbryantuk
Thank you! Questions?
39
getambassador.io/products/telepresence
getambassador.io/testing-with-telepresence-and-docker
Easy Debugging of Spring Boot Microservices Running on
Kubernetes
AL Developer O
ff
ice Hours
db@datawire.io / @danielbryantuk