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
2. Welcome! Thanks for joining us
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…
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