Microservices snakes and ladders

Microservices aren’t new but the last few years have certainly seen a lot of successful implementations of the pattern. The promise of high scalability has attracted engineering teams to it like moths to a flame. There are plethora of benefits but they are accompanied by an ever growing set of technical and nontechnical pitfalls. As the shininess of microservices gradually decline, there are important lessons to learn from our scars. We will look at why microservices implementation fail, How to avoid the pitfalls and most importantly whether you need to ditch your trusty monolith after all.

Transcript

1. A Game of Snakes
   & Ladders Called
   Microservices
   Dasith Wijesiriwardena
   Twitter: @dasiths Web: https://dasith.me
   

   View Slide

2. Welcome!
   Thanks for joining us
   

   View Slide

3. View Slide

4. 01
   Agenda
   Beyond The Marketing Pitch
   Microservices aren’t new
   Data & Bounded Contexts
   Ownership is just the beginning
   Eventually Consistent
   Immediately painful
   Hidden Complexity
   A modern Trojan horse
   05
   06
   03
   02 Organisational Challenges
   Clapping with one hand
   Talk Over The Wire to Me
   REST, GraphQL, gRPC or event driven?
   04
   

   View Slide

5. Domain
   Driven
   Design
   • Focus on the business requirements
   •Technology always comes second
   

   View Slide

6. Beyond The
   Marketing Pitch
   Microservices aren’t new
   1
   

   View Slide

7. Promise of
   Microservices
   •Scalability
   •Team Autonomy
   •Agility
   

   View Slide

8. Promise of
   Microservices
   •Scalability
   •Team Autonomy
   •Agility
   

   View Slide

9. Promise of
   Microservices
   •Scalability
   •Team Autonomy
   •Agility
   

   View Slide

10. Promise of
    Microservices
    •Scalability
    •Team Autonomy
    •Agility
    

    View Slide

11. Promise of
    Microservices
    •Scalability
    •Team Autonomy
    •Agility
    

    View Slide

12. Do You Need
    Microservices?
    •Do you have a modular
    monolith?
    •Is the domain well
    understood?
    •Are you doing it for
    scalability advantages?
    

    View Slide

13. Do You Need
    Microservices?
    •Do you have a modular
    monolith?
    •Is the domain well
    understood?
    •Are you doing it for
    scalability advantages?
    

    View Slide

14. Do You Need
    Microservices?
    •Do you have a modular
    monolith?
    •Is the domain well
    understood?
    •Are you doing it for
    scalability advantages?
    

    View Slide

15. Do You Need
    Microservices?
    •Do you have a modular
    monolith?
    •Is the domain well
    understood?
    •Are you doing it for
    scalability advantages?
    

    View Slide

16. (Sad) History of Microservices
    

    View Slide

17. Messaging mechanism by which
    OBJECTS DISTRIBUTED over a
    network, can COMMUNICATE with
    each other
    Common Object
    Request Broker Architecture
    (CORBA)
    

    View Slide

18. Same Old
    New Thing
    • 1958 – LISP Atoms
    • 1960 – Object Oriented Programming
    • 1970 – Small Talk
    • 1973 – Actor Model
    • 1991 – CORBA
    • SOA ?
    

    View Slide

19. OBJECTS with well defined
    responsibilities,
    COMMUNICATING over a
    MEDIUM, to complete a task
    

    View Slide

20. Organisational
    Challenges
    Clapping with one hand
    2
    

    View Slide

21. Conway's Law
    Organizations which design systems ... are
    constrained to produce designs which are copies
    of the communication structures of these
    organizations
    

    View Slide

22. • Think vertical, not horizontal
    • Security? DevOps? Performance?
    • Own your outcomes
    • Direct communication with stake holders
    Cross Functional
    Teams
    

    View Slide

23. • Think vertical, not horizontal
    • Security? DevOps? Performance?
    • Own your outcomes
    • Direct communication with stake holders
    Functional
    DevOps
    Development
    QA
    Cross Functional
    Teams
    

    View Slide

24. • Think vertical, not horizontal
    • Security? DevOps? Performance?
    • Own your outcomes
    • Direct communication with stake holders
    Functional
    DevOps
    Development
    QA
    Cross Functional
    Teams
    

    View Slide

25. • Think vertical, not horizontal
    • Security? DevOps? Performance?
    • Own your outcomes
    • Direct communication with stake holders
    Cross Functional
    Teams
    

    View Slide

26. Cross Functional
    Teams
    • Think vertical, not horizontal
    • Security? DevOps? Performance?
    • Own your outcomes
    • Direct communication with stake holders
    

    View Slide

27. Death by Polyglot
    •Mastery Productivity
    • Resume driven development
    

    View Slide

28. Frameworks
    •Avoid! Avoid! Avoid!
    •Share only the bare
    minimum
    

    View Slide

29. •Avoid! Avoid! Avoid!
    •Share only the bare
    minimum
    Frameworks
    

    View Slide

30. Data & Bounded
    Contexts
    Ownership is just the beginning
    3
    

    View Slide

31. Ownership
    Once upon a time…
    One monolith, one data store
    

    View Slide

32. Ownership
    Let’s do microservices…
    

    View Slide

33. Ownership
    Let’s do microservices…
    without thinking about data
    

    View Slide

34. Ownership
    Bad: No clear ownership
    

    View Slide

35. Ownership
    Make a field
    optional
    Bad: No clear ownership
    

    View Slide

36. Ownership
    Make a field
    optional
    Bad: No clear ownership
    

    View Slide

37. Ownership
    Make a field
    optional
    Bad: No clear ownership
    

    View Slide

38. OBJECTS with well defined
    responsibilities,
    COMMUNICATING over a
    MEDIUM, to complete a task
    

    View Slide

39. Ownership
    Suppliers
    Machines
    Customers
    Good: One microservice
    owns each table or entity
    

    View Slide

40. Ownership
    Better:
    • Owned data store
    • External access via interface
    Machines Customers Suppliers
    

    View Slide

41. Ownership
    Better:
    • Owned data store
    • External access via interface
    Machines Customers Suppliers
    Scalability
    

    View Slide

42. Ownership
    Best: Clear ownership of its
    own world view (bounded
    context)
    

    View Slide

43. Ownership
    Best: Clear ownership of its
    own world view (bounded
    context)
    Scalability,
    Agility,
    Team Autonomy
    

    View Slide

44. Distributed
    Transactions
    Looking for two phase
    commit (2PC) ?
    

    View Slide

45. Distributed
    Transactions
    Hint: You have incorrect
    bounded contexts
    

    View Slide

46. Talk Over The
    Wire to Me
    REST, GraphQL, gRPC or event driven?
    4
    

    View Slide

47. OBJECTS with well defined
    responsibilities,
    COMMUNICATING over a
    MEDIUM, to complete a task
    

    View Slide

48. Medium of
    Transport
    Makes all the difference
    

    View Slide

49. Medium of
    Transport
    Safety of in-process calls
    

    View Slide

50. Medium of
    Transport
    Uncertainty of network calls
    

    View Slide

51. Medium of
    Transport
    Closer look at the network
    

    View Slide

52. Did You Assume?
    •Network is reliable
    •Latency is zero
    •Infinite bandwidth
    •No overheads
    •Is secure
    

    View Slide

53. Did You Assume?
    •Network is reliable
    •Latency is zero
    •Infinite bandwidth
    •No overheads
    •Is secure
    

    View Slide

54. Designing
    Your API
    So many choices
    Your Footer Here
    

    View Slide

55. REST
    • Simple
    • Suitable for CRUD
    • Domain comes first
    • OpenAPI (Swagger) ⟹ Great fit
    for public facing interface
    

    View Slide

56. GraphQL
    • Heterogeneous data
    requirements? Great!
    • Not just for querying
    • Subscriptions
    • Mutations
    

    View Slide

57. gRPC :
    Universal RPC framework
    • HTTP/2 and Protobuf
    • Suitable for actions heavy APIs
    • Contract unlikely to change? Good!
    • Few well known clients? Great!
    • Polyglot environment? Great!
    

    View Slide

58. Know Your
    Audience
    Sequential vs Event Driven API
    Your Footer Here
    

    View Slide

59. Sequential
    Communication
    •Request + Response
    •Great for querying
    •Simple workflow
    

    View Slide

60. But, Also
    Think About…
    •Tightly coupled external
    dependencies
    •Owning your SLA
    •If (when) dependencies fail?
    • Retrying, Circuit Breaker etc.
    

    View Slide

61. But, Also
    Think About…
    •Tightly coupled external
    dependencies
    •Owning your SLA
    •If (when) dependencies fail?
    • Retrying, Circuit Breaker etc.
    

    View Slide

62. Event Driven
    •Publish + Subscribe
    •Loosely coupled
    •Scalable
    •Greater resiliency
    (Dead letter queues etc.)
    

    View Slide

63. Event Driven
    •Publish + Subscribe
    •Loosely coupled
    •Scalable
    •Greater resiliency
    (Dead letter queues etc.)
    Scalability,
    Resiliency
    

    View Slide

64. •Delivery guarantee
    • Idempotent Handlers?
    •Versioning
    •Payload size
    •Eventual consistency
    But, Also
    Think About…
    

    View Slide

65. •Delivery guarantee
    • Idempotent Handlers?
    •Versioning
    •Payload size
    •Eventual consistency
    But, Also
    Think About…
    

    View Slide

66. But, Also
    Think About…
    •Delivery guarantee
    • Idempotent Handlers?
    •Versioning
    •Payload size
    •Eventual consistency
    

    View Slide

67. Eventually
    Consistent
    Immediately painful
    5
    

    View Slide

68. OBJECTS with well defined
    responsibilities,
    COMMUNICATING over a
    MEDIUM, to complete a task
    

    View Slide

69. Transaction
    Safety Wheels
    Not for highly available
    distributed systems
    Your Footer Here
    

    View Slide

70. Race Conditions
    • Don’t try to prevent
    • Compensate instead
    https://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
    Gregor Hohpe
    

    View Slide

71. Race Conditions
    • Look to the real world
    • Dig deeper into the domain
    http://udidahan.com/2010/08/31/race-conditions-dont-exist/
    

    View Slide

72. Transactions
    Tempted to use distributed
    transactions to prevent
    race conditions?
    

    View Slide

73. Transactions
    Tempted to use distributed
    transactions to prevent
    race conditions?
    Don’t do it *
    

    View Slide

74. NewSQL
    Promises “highly” available
    databases with strict
    consistency.
    

    View Slide

75. NewSQL & CAP Theorem
    • https://www.microsoft.com/en-
    us/research/publication/transactions-distributed-actors-cloud-2/
    • https://cloud.google.com/blog/products/gcp/inside-cloud-
    spanner-and-the-cap-theorem
    • https://www.cockroachlabs.com/blog/limits-of-the-cap-
    theorem/
    

    View Slide

76. Hidden
    Complexity
    A modern Trojan horse
    6
    

    View Slide

77. UI Monolith
    The real bottleneck
    Your Footer Here
    

    View Slide

78. UI Monolith
    

    View Slide

79. UI Monolith
    Bottleneck
    

    View Slide

80. Micro Front-ends
    

    View Slide

81. Micro Front-ends
    Scalability,
    Agility,
    Team Autonomy
    

    View Slide

82. Be Careful…
    • Too many micro front-
    ends large payload
    • Framework
    incompatibilities
    

    View Slide

83. Be Careful…
    • Too many micro front-
    ends large payload
    • Framework
    incompatibilities
    

    View Slide

84. Distributed
    Monolith
    Worst of two worlds
    Your Footer Here
    

    View Slide

85. Distributed
    Monolith
    • You’ve distributed the logic
    of your monolith? That
    was the plan.
    • But they can’t function
    without each other? Bad!
    

    View Slide

86. Distributed
    Monolith
    

    View Slide

87. Distributed
    Monolith
    

    View Slide

88. Distributed
    Monolith
    

    View Slide

89. Distributed
    Monolith
    

    View Slide

90. Distributed
    Monolith
    

    View Slide

91. Distributed
    Monolith
    

    View Slide

92. Distributed
    Monolith
    

    View Slide

93. Distributed
    Monolith
    • Complexity of a distributed
    system
    • Downsides of a Monolith
    

    View Slide

94. Distributed
    Monolith
    • Complexity of a distributed
    system
    • Downsides of a Monolith
    

    View Slide

95. Pains of
    Distributed
    Systems
    Figuring out the
    domain is just the
    beginning
    Your Footer Here
    

    View Slide

96. Inter-Microservice
    Communication
    

    View Slide

97. Cross Cutting
    Concerns
    • Service Discovery
    • Load Balancing
    •Circuit Breaker, Retry etc
    • Dynamic Routing
    •Security & Access Control
    • Monitoring & Tracing
    

    View Slide

98. Delegate to
    Sidecar
    https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
    

    View Slide

99. Service Mesh
    https://www.nginx.com/blog/what-is-a-service-mesh/
    

    View Slide

100. What About?
     • Deployment
     • Auto scaling
     •Chaos engineering
     etc.. etc.. etc..
     

     View Slide

101. Conclusion
     What should you take away
     from this?
     

     View Slide

102. Let’s Revisit
     •Do you have a modular
     monolith?
     •Is the domain well
     understood?
     •Are you doing it for
     scalability advantages?
     

     View Slide

103. Let’s Revisit
     •Do you have a modular
     monolith?
     •Is the domain well
     understood?
     •Are you doing it for
     scalability advantages?
     

     View Slide

104. Let’s Revisit
     •Do you have a modular
     monolith?
     •Is the domain well
     understood?
     •Are you doing it for
     scalability advantages?
     

     View Slide

105. Let’s Revisit
     •Do you have a modular
     monolith?
     •Is the domain well
     understood?
     •Are you doing it for
     scalability advantages?
     

     View Slide

106. Monolith’s Have
     Their Place
     Solve business problems first,
     Technology second…
     Your Footer Here
     

     View Slide

107. It’s a Journey
     Rome wasn’t built in a day…
     Your Footer Here
     

     View Slide

108. Learn From The
     Past Experiences
     Microservices aren’t new
     Your Footer Here
     

     View Slide

109. Your Footer Here
     Do It For The
     Right Reasons
     Timing is everything…
     

     View Slide

110. View Slide

111. Thank You!
     Do you have any questions?
     J O H N S H O W E E T
     P R E S E N T A T I O N E X P E R T
     @dasiths
     dasith.me
     

     View Slide