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

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.


João Rosa

June 18, 2019


  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

  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

  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…

  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 -

  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

  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