Pro Yearly is on sale from $80 to $50! »

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.

B4c7e56ec325c0c55d5e29c7ab42e49f?s=128

Dasith Wijesiriwardena

September 06, 2019
Tweet

Transcript

  1. A Game of Snakes & Ladders Called Microservices Dasith Wijesiriwardena

    Twitter: @dasiths Web: https://dasith.me
  2. Welcome! Thanks for joining us

  3. None
  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
  5. Domain Driven Design • Focus on the business requirements •Technology

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

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

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

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

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

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

  12. Do You Need Microservices? •Do you have a modular monolith?

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

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

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

    •Is the domain well understood? •Are you doing it for scalability advantages?
  16. (Sad) History of Microservices

  17. Messaging mechanism by which OBJECTS DISTRIBUTED over a network, can

    COMMUNICATE with each other Common Object Request Broker Architecture (CORBA)
  18. Same Old New Thing • 1958 – LISP Atoms •

    1960 – Object Oriented Programming • 1970 – Small Talk • 1973 – Actor Model • 1991 – CORBA • SOA ?
  19. OBJECTS with well defined responsibilities, COMMUNICATING over a MEDIUM, to

    complete a task
  20. Organisational Challenges Clapping with one hand 2

  21. Conway's Law Organizations which design systems ... are constrained to

    produce designs which are copies of the communication structures of these organizations
  22. • Think vertical, not horizontal • Security? DevOps? Performance? •

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

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

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

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

    DevOps? Performance? • Own your outcomes • Direct communication with stake holders
  27. Death by Polyglot •Mastery Productivity • Resume driven development

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

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

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

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

  32. Ownership Let’s do microservices…

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

  34. Ownership Bad: No clear ownership

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

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

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

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

    complete a task
  39. Ownership Suppliers Machines Customers Good: One microservice owns each table

    or entity
  40. Ownership Better: • Owned data store • External access via

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

    interface Machines Customers Suppliers Scalability
  42. Ownership Best: Clear ownership of its own world view (bounded

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

    context) Scalability, Agility, Team Autonomy
  44. Distributed Transactions Looking for two phase commit (2PC) ?

  45. Distributed Transactions Hint: You have incorrect bounded contexts

  46. Talk Over The Wire to Me REST, GraphQL, gRPC or

    event driven? 4
  47. OBJECTS with well defined responsibilities, COMMUNICATING over a MEDIUM, to

    complete a task
  48. Medium of Transport Makes all the difference

  49. Medium of Transport Safety of in-process calls

  50. Medium of Transport Uncertainty of network calls

  51. Medium of Transport Closer look at the network

  52. Did You Assume? •Network is reliable •Latency is zero •Infinite

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

    bandwidth •No overheads •Is secure
  54. Designing Your API So many choices Your Footer Here

  55. REST • Simple • Suitable for CRUD • Domain comes

    first • OpenAPI (Swagger) ⟹ Great fit for public facing interface
  56. GraphQL • Heterogeneous data requirements? Great! • Not just for

    querying • Subscriptions • Mutations
  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!
  58. Know Your Audience Sequential vs Event Driven API Your Footer

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

  60. But, Also Think About… •Tightly coupled external dependencies •Owning your

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

    SLA •If (when) dependencies fail? • Retrying, Circuit Breaker etc.
  62. Event Driven •Publish + Subscribe •Loosely coupled •Scalable •Greater resiliency

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

    (Dead letter queues etc.) Scalability, Resiliency
  64. •Delivery guarantee • Idempotent Handlers? •Versioning •Payload size •Eventual consistency

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

    But, Also Think About…
  66. But, Also Think About… •Delivery guarantee • Idempotent Handlers? •Versioning

    •Payload size •Eventual consistency
  67. Eventually Consistent Immediately painful 5

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

    complete a task
  69. Transaction Safety Wheels Not for highly available distributed systems Your

    Footer Here
  70. Race Conditions • Don’t try to prevent • Compensate instead

    https://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html Gregor Hohpe
  71. Race Conditions • Look to the real world • Dig

    deeper into the domain http://udidahan.com/2010/08/31/race-conditions-dont-exist/
  72. Transactions Tempted to use distributed transactions to prevent race conditions?

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

    Don’t do it *
  74. NewSQL Promises “highly” available databases with strict consistency.

  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/
  76. Hidden Complexity A modern Trojan horse 6

  77. UI Monolith The real bottleneck Your Footer Here

  78. UI Monolith

  79. UI Monolith Bottleneck

  80. Micro Front-ends

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

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

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

    • Framework incompatibilities
  84. Distributed Monolith Worst of two worlds Your Footer Here

  85. Distributed Monolith • You’ve distributed the logic of your monolith?

    That was the plan. • But they can’t function without each other? Bad!
  86. Distributed Monolith

  87. Distributed Monolith

  88. Distributed Monolith

  89. Distributed Monolith

  90. Distributed Monolith

  91. Distributed Monolith

  92. Distributed Monolith

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

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

    of a Monolith
  95. Pains of Distributed Systems Figuring out the domain is just

    the beginning Your Footer Here
  96. Inter-Microservice Communication

  97. Cross Cutting Concerns • Service Discovery • Load Balancing •Circuit

    Breaker, Retry etc • Dynamic Routing •Security & Access Control • Monitoring & Tracing
  98. Delegate to Sidecar https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar

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

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

    etc.. etc..
  101. Conclusion What should you take away from this?

  102. Let’s Revisit •Do you have a modular monolith? •Is the

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

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

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

    domain well understood? •Are you doing it for scalability advantages?
  106. Monolith’s Have Their Place Solve business problems first, Technology second…

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

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

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

    is everything…
  110. None
  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