How to make a technical decision

Transcript

2. Hello
3. My second time here
5. Anton Davydov github.com/davydovanton twitter.com/anton_davydov davydovanton.com
9. Core member
11. twitch.tv/davydovanton
12. • OpenSource evangelist • Technical consulting
13. Stickers
14. • Memes • Coffee • Beer • Kendo • Psychology • jRPG • SW-2039-0208-4228 / 3DS also welcome • How to draw images for presentations
16. SOA in toptal
17. service oriented architecture
18. Microservices
19. Very specific and will work only in toptal
20. Why?
21. We have a specific requirements and this requirements related only for our company
26. Instead make a decision we’re trying to find a solution
28. How we made architectural decision in toptal
29. Attention: experimental talk
30. Zero line of code
31. Why developers should think about it?
32. 0. personal projects
33. How to start using own library in the company?
34. 1. “I think it will be good for us”
35. Works only in small offices
36. Or with opinion leaders
38. 2. Business wants to understand why they need to spend money and time for something
40. 3. Sharing knowledge
41. Private discussions, meetings and public channels in slack
42. Hard to find information without knowledge where to find it
43. 4. Learning and improving code
44. Loosing context of decision
45. Decision cycle
46. problem -> ??? -> solution
47. problem -> -> solution
49. Problem
50. Problem Requirements
51. Technology list
53. Technical requirements
54. Architecture requirements
55. Business requirements
56. Current implementation
57. Problem Requirements Research solutions
58. Google
59. Books
60. Example: data composition approaches
62. Chats
63. Problem Requirements Research solutions Map solutions to requirements
65. PoC
66. Proof of concept
67. Expensive
68. Choose 2 solutions and make PoC for them
69. Problem Requirements Research solutions Map solutions to requirements Decision
70. Based on table/PoC/etc
71. Describe why you dropped or choose solution
72. What to do if solutions absolutely equal?
73. Choose simplest solution
74. Calculate price
75. Example: image service
76. imgix vs imgproxy
77. Check maintainers
78. Example
79. Apache Thrift
80. Thrift is an interface definition language and binary communication protocol used for defining and creating services for numerous languages. … written in a variety of languages and frameworks, including ActionScript, C, C++,[3] C#, Cappuccino, Cocoa, Delphi, Erlang, Go, Haskell, Java, Node.js, Objective-C, OCaml, Perl, PHP, Python, Ruby, Rust, Smalltalk and Swift. ....
84. PROFIT
85. Requirements Research solutions Map solutions to requirements Decision Problem Handling results
86. Can be anything
87. ADR
88. Architecture Decision Records
89. Blog posts
90. Markdown
91. Emacs-org
92. Rules
93. Context of problem
94. Who made this decision
95. Provide pros and cons
96. Link all research information
97. # [short title of solved problem and solution] * Status: * Deciders: * Date: ## Context and Problem Statement ## Decision Drivers ## Considered Options ## Decision Outcome ### Positive Consequences ### Negative Consequences ## Pros and Cons of the Options ## Links
98. Share results with everyone
99. Example: slack retro meetings weekly updates @dev-all in email
100. Keep all decision in one place
101. GitHub Blog posts Confluence space Notion space Trello
102. Let’s talk about reality
103. SOA
104. SOA is simple
105. Infrastructure * How to deploy apps separately * Docker or something else * How to share resources * cloud or bare metal * CI and CD * Docker regestry * slack bots * local k8s cluster
106. Data * data evolution * How to store and calculate state * Allowed DB * How to share data between services
107. Sync communications * frontend <> backend * backend <> backend * How to handle failed services, DB or integration * Distributed tracing * Diagram of communications * Compatibility level * Documentation
108. Async communication * Message bus * Message schema evolution * Schema registry * How to consume and produce data * Distributed tracing * Diagram of communications * Compatibility level * Documentation
109. Gateways * api gateway * GQL gateway (if needed) * schema stitching * JSON API to GQL
110. Business logic and domains * distributed transactions * distributed locks * DDD and domain sharing * business events * microservice chassis
111. Management, teams and processes
112. Testing * contract testing * chaos engenering * e2e testing
113. Local development
114. AuthN / AuthZ
115. Observability * App level * Logs * Metrics * Error handling * Company level * Services diagram * Service characteristics * Service owning
116. Analytics * ETL * How to get data from services * Event based approach * How to work with DS models?
117. And more
118. Example from real live
119. Sync communications * frontend <> backend * backend <> backend * How to handle failed services, DB or integration * Distributed tracing * Diagram of communications * Compatibility level * Documentation
120. Sync communications * frontend <> backend * backend <> backend * How to handle failed services, DB or integration * Distributed tracing * Diagram of communications * Compatibility level * Documentation
121. Step 1
122. Requirements Research solutions Map solutions to requirements Decision Problem Handling results
123. Avoid proliferation of solutions for sync communication in the future as the number of services keeps growing.
124. Step 2
125. Requirements Research solutions Map solutions to requirements Decision Problem Handling results
126. • Uses JSON for serialization • Works with HTTP/1.1 • IDL + Tolerant reader • Bulshitless discussions • Pact integration • Simple documentation • Works with ruby, node.js, go, elixir, java • Easy for debugging
127. Step 3
128. Requirements Research solutions Map solutions to requirements Decision Problem Handling results
129. Google
130. • JSON API • JSON RPC • gRPC • avroRPC • thriftRPC • GraphQL
131. Other experience
132. • Shopify - GQL • Github - BERT-RPC and GQL • Gitlab - nothing • Airbnb - Thrift • Heroku - JSON API • Coinbase - gRPC • Cookpad - gRPC • Twitter - Thrift
133. Interesting use cases
134. Twitch
135. Twirp
136. gRPC over HTTP/1.1
137. JSON serialisation
138. Netflix
140. Step 4
141. Requirements Research solutions Map solutions to requirements Decision Problem Handling results
143. PoC
145. Step 5
146. Requirements Research solutions Map solutions to requirements Decision Problem Handling results
149. We made notes about all dropped solution
151. Step 6
152. Requirements Research solutions Map solutions to requirements Decision Problem Handling results
153. Blog post
155. All meetings notes
159. Researched information + PoC examples for the team who will implement communications
160. Current state
161. Everyone from toptal can read how and why we made this research
163. I used all this information for the presentation’s example
164. Requirements Research solutions Map solutions to requirements Decision Problem Handling results
165. Next steps
166. Share research with everyone
167. Start writing context of each decision
168. # [short title of solved problem and solution] * Status: * Deciders: * Date: ## Context and Problem Statement ## Decision Drivers ## Considered Options ## Decision Outcome ### Positive Consequences ### Negative Consequences ## Pros and Cons of the Options ## Links
169. # [short title of solved problem and solution] * Status: * Deciders: * Date: ## Context and Problem Statement ## Decision Drivers ## Considered Options ## Decision Outcome ### Positive Consequences ### Negative Consequences ## Pros and Cons of the Options ## Links
170. Make special place for decisions
171. Try to use ADRs if you don’t want to spend much time for researching
172. Share your progress with colleagues and start discussion
173. Thank you ❤ twitter.com/anton_davydov github.com/davydovanton mail@davydovanton.com davydovanton.com