Microservices are an antipattern

Microservices are an antipattern

Fad1e9ed293fc5b3ec7d4abdffeb636f?s=128

Lindsay Holmwood

April 18, 2019
Tweet

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)