Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices snakes and ladders

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.

Dasith Wijesiriwardena

September 06, 2019
Tweet

More Decks by Dasith Wijesiriwardena

Other Decks in Programming

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