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

26. None

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)