Microservices are an antipattern

Transcript

1. Microservices are an antipattern Lindsay Holmwood
2. Microservices are an antipattern Lindsay Holmwood
3. Why microservices?
4. Design strategy to manage complexity in our systems
5. Design strategy to manage complexity in our systems
6. If the system or team get too big, we: 1. Split the system
7. If the system or team get too big, we: 1. Split the system
8. If the system or team get too big, we: 2. Split the team
9. Popularised by the devops movement
10. Popularised by the devops movement
11. CD + containers were the drivers
12. CD + containers were the drivers
13. In use at the big end of town
14. “It works for Google, so we’ll scale it down and get the same benefits!”
15. We cargo culted a design strategy without understanding the tradeoffs
16. Real talk: The smallest microservice at Google probably does more transactions than the largest service in your organisation.
17. Real talk: We took a pattern for managing huge systems, extrapolated it down to our size, and hoped it worked.
18. Real talk: Hope is not a strategy.
19. Some downsides you should think about:
20. Some downsides you should think about:
21. You’re replacing function calls with network calls
22. Source: “Systems Performance: Enterprise and the Cloud” by Brendan Gregg
23. Is that latency worth it?
24. What hard limits are you imposing to control unpredictability?
25. Microservices are a systems multiplier for your shitty code
27. How is your ◦ modularity? ◦ isolation? ◦ encapsulation?
28. Refactor first
29. Then scale when the performance impacts users
30. 1. Make it work 2. Make it right 3. Make it fast
31. 1. Make it work 2. Make it right 3. Make it fast Refactor
32. 1. Make it work 2. Make it right 3. Make it fast Refactor Microservice
33. Microservices have a higher cost of ownership
34. Operational requirements: ◦ CD pipelines ◦ Network & compute & storage ◦ Logging ◦ Monitoring ◦ Tracing & observability
35. Security requirements: ◦ Authentication ◦ Identity ◦ Monitoring
36. This costs more (both in systems bills and engineering time)
37. But what if we just… didn’t?
38. But what if we just… didn’t?
39. Problems are harder to debug
40. Incidents have > MTTD & MTTR
41. Delivery slows
42. Increased communication + coordination overhead between teams
43. Sequencing of changes across multiple services
44. Poor service boundaries? You have to get multiple teams moving in the same direction to deliver a change.
45. Stakeholders for technical changes are rarely exclusively technical
46. Requires coordination across disciplines like product, design, marketing, analytics, …
47. You need established and understood communication paths
48. You need established and understood change coordination
49. You need established cultural norms for resolving conflict
50. Microservices are an effective way to separate concerns in complex systems
51. Microservices are an inefficient way of organising people in organisations < 1,000 people
52. The smaller the org, the smaller the return
53. You are not Google/Netflix/ AWS/Facebook/…
54. Do the job you have, not the job you want.
55. Thank you! (fight me)