Observe the System: Two Sides of the Same Coin @ Test Master Meetup

Observability is one of the buzzwords of the day. We have the 3 pillars, a plethora of tools, great books. We moved our monolithic apps that lived in the datacenter to distributed microservices in the cloud, with the promised land of cost savings and an Agile organisation. However, are we delivering more business value?

Today, we send metrics to the systems managed by the Operations Team and at the same time to the Business Intelligence systems. However, we have the will for our teams to have autonomy and ownership of the systems which they put into production. How can we merge the best of both worlds, giving autonomy to our development teams, have a reliable system and increase the business value delivered?

Join João on his journey, using collaboration techniques from the DDD community to discover the Domain Events that generated business value and how it is related to the technical components of the system. During his talk, he will address the challenges of bringing the two sides of the same coin together, creating a healthy environment among all parties.

Transcript

1. Observe the System: Two Sides of the Same Coin Test Masters Series – Testing in Production
2. 2 Strategic Software Delivery Consultant @ Xebia DDDer, EventStormer, Tech Enthusiast Food lover, you can find me in a beach reading a book Expat @ The Netherlands @joaoasrosa
3. 3 © João Rosa @joaoasrosa
4. 4 How did I end up here? @joaoasrosa
5. 5 And you? @joaoasrosa
6. 6 Photo by Saketh Garuda on Unsplash @joaoasrosa
7. 7 Well, we measure… @joaoasrosa
8. 8 Photo by Kevin Grieve on Unsplash @joaoasrosa
9. 9 Myself, with a confused look: Ok, how do you know the impact of the product with the users? @joaoasrosa
10. @joaoasrosa
11. That awkward silence… @joaoasrosa
12. 12 Anti-pattern #1: Technical measurement without the user in mind @joaoasrosa
13. 13 We are a DevOps team… @joaoasrosa
14. 14 Photo by Olesya Grichina on Unsplash @joaoasrosa
15. 15 Anti-pattern #2: Monitoring as single responsibility (aka Monitoring-as-a-Job - credits to Mike Julian) @joaoasrosa
16. 16 We monitoring everything… @joaoasrosa
17. 17 Photo by Markus Spiske on Unsplash @joaoasrosa
18. 18 Myself, trying to get to the bottom of it: What are the benefits of the yellow hammer, in your landscape? @joaoasrosa
19. The yellow hammer is the best! @joaoasrosa
20. The yellow hammer is the best! Or do you think that purple hammer is better because <insert reason>? @joaoasrosa
21. 21 Anti-pattern #3: One tool to rule them all! @joaoasrosa
22. 22 "Silos" by warrick1 is licensed under CC BY-ND 2.0 @joaoasrosa
23. 23 Photo by Yung Chang on Unsplash @joaoasrosa
24. 24 Photo by NeONBRAND on Unsplash @joaoasrosa
25. 25 Back to the Observability topic… @joaoasrosa
26. 26 Photo by Christoph Schmid on Unsplash @joaoasrosa
27. 27 Logging Metrics Tracing @joaoasrosa
28. 28 From Site Reliability Engineering Book - https://landing.google.com/sre/sre-book/chapters/part3/ @joaoasrosa
29. 29 Not the focus today… @joaoasrosa
30. 30 @joaoasrosa And more not listed here!
31. 31 But what I use to connect all the dots… @joaoasrosa
32. 32 To deliver a reliable and usable product that satisfies the users needs @joaoasrosa
33. 33 @joaoasrosa
34. 34 @joaoasrosa
35. 35 @joaoasrosa
36. 36 @joaoasrosa
37. 37 @joaoasrosa
38. 38 @joaoasrosa Bounded Context - Language boundaries - Specific model for the Problem Space - Isolate concepts (models) - Communicate over Domain Events From more check: http://domainlanguage.com/ddd/reference/
39. 39 @joaoasrosa From Using domain analysis to model microservices - https://docs.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis
40. 40 @joaoasrosa
41. 41 @joaoasrosa
42. 42 @joaoasrosa
43. 43 @joaoasrosa
44. 44 @joaoasrosa Pattern #1: Measure Events on the borders of the Bounded Context
45. 45 @joaoasrosa Pattern #1 implementation examples: Events in a queue Calls to an API endpoint Events generated by a batch process
46. 46 @joaoasrosa
47. 47 @joaoasrosa
48. 48 @joaoasrosa
49. 49 @joaoasrosa
50. 50 @joaoasrosa Pattern #2: Measure Event Flows concerning the Business Process(es)
51. 51 @joaoasrosa Pattern #2 implementation example: Events tracing - Using OpenTracing API - https://opentracing.io/ - Crafted, CorrelationID
52. 52 @joaoasrosa
53. 53 @joaoasrosa Pattern #3: Measure Events within the Bounded Context
54. 54 @joaoasrosa Pattern #3 implementation examples: Structured logging Metrics
55. 55 @joaoasrosa Let’s have a quizzzzz!
56. 56 @joaoasrosa 1. Buying a ticket for a movie (via an mobile app) 2. The app reserves my seat for 10 minutes 3. I can only pay using iDeal 4. If I don’t pay within the 10 minute window the seats are released for other potential customer Scenario
57. 57 @joaoasrosa What if I pay within the 10 minute window (let’s say 9:49) but in the meantime the seat was released (lag time between the payment acknowledgment)? Question
58. 58 My suggestion… @joaoasrosa
59. 59 @joaoasrosa Pattern #4: Use Pivotal Events to validate the option of implementing a process
60. 60 @joaoasrosa Pattern #4 implementation examples: Metrics
61. 61 @joaoasrosa Pattern #4 implementation examples: Metrics However, we use it to drive business value
62. 62 @joaoasrosa How about visualisations?
63. 63 @joaoasrosa How about visualisations? aka, Dashboards
64. 64 @joaoasrosa Pattern #5: Start your Dashboards from a Functional perspective Later move to the Technical ones (drill-down), which supports the Functional Dashboards
65. 65 @joaoasrosa Pattern #5 implementation examples:
66. 66 Photo by Camylla Battani on Unsplash @joaoasrosa