Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Stop Building Services, Episode I: The Phantom Menace

Stop Building Services, Episode I: The Phantom Menace

A 45 minute talk about how to make architecture decisions, and case studies of building services; presented at at ArrrrgCamp 2015

E0231b87a02961b6246b019c07238d55?s=128

Rachel Myers

October 02, 2015
Tweet

More Decks by Rachel Myers

Other Decks in Programming

Transcript

  1. Stop Building Services @rachelmyers

  2. RailsBridge @rachelmyers

  3. RailsBridge BridgeFoundry @rachelmyers

  4. Inexpensive (ARM) Dev Environments @rachelmyers

  5. Ruby Engineer at GitHub @rachelmyers

  6. Stop Building Services Episode 1: The Phantom Menace @rachelmyers

  7. Service Oriented Architecture

  8. Monoliths are big

  9. Monoliths are big Monoliths are hard to change

  10. Monoliths are big Monoliths are hard to change Monoliths don’t

    work for big teams
  11. Monoliths are big Monoliths are hard to change Monoliths don’t

    work for big teams Monoliths make apps slow
  12. Monoliths are big Monoliths are hard to change Monoliths don’t

    work for big teams Monoliths make apps slow Monoliths aren’t web scale
  13. How should we make architecture decisions? Now Paging Karl Popper

    on falsifiability
  14. Monoliths are big Monoliths are hard to change Monoliths don’t

    work for big teams Monoliths make apps slow Monoliths aren’t web scale
  15. Falsifiable: Is there any evidence that could change my mind?

  16. 1. We should use evidence 2. Criteria to look for

    3. Case Studies
  17. 1. We should use evidence 2. Criteria to look for

    3. Case Studies (Evidence)
  18. 1. Make our product more resilient and fault tolerant Architecture

    should:
  19. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. Architecture should:
  20. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  21. Main App Service Service Service Service Conway’s Law

  22. Product Object User Object Cart Object Conway’s Law

  23. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  24. 1. We should use evidence 2. Criteria to look for

    3. Case Studies
  25. Extracting Tangled Code Case Study 1 An Identity Service

  26. The Javascript

  27. The Ruby # This class encapsulates behavior for hats that

    are for # sale as well as hat samples we might sell. class Hat belongs_to :votable_hat, class_name: :Hat # Public: Adds a Hat to a Cart # Returns the Hat def add_to(cart) … end # Public: Vote for a sample Hat # Returns a Hat def vote_yes(user) … end end
  28. The Ruby # This class encapsulates behavior for hats that

    are for # sale as well as hat samples we might sell. class Hat belongs_to :votable_hat, class_name: :Hat # Public: Adds a Hat to a Cart # Returns the Hat def add_to(cart) … end # Public: Vote for a sample Hat # Returns a Hat def vote_yes(user) … end end
  29. The Ruby # This class encapsulates behavior for hats that

    are for # sale as well as hat samples we might sell. class Hat belongs_to :votable_hat, class_name: :Hat # Public: Adds a Hat to a Cart # Returns the Hat def add_to(cart) … end # Public: Vote for a sample Hat # Returns a Hat def vote_yes(user) … end end
  30. 1. Manage complexity Project Goals:

  31. Main App Service Main DB Service DB

  32. Main App Service Main DB Service DB

  33. Main App Service Main DB Service DB

  34. Main App Service Main DB Service DB

  35. 1. Drew the wrong lines for services; reinforced complexity. Failures:

  36. Locking in what you meant to lock out {

  37. 1. Drew the wrong lines for services; reinforced complexity 2.

    Mixed Service and Library strategies Failures:
  38. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  39. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  40. github.com/github/scientist

  41. github.com/github/scientist Easy Rewrites with Ruby and Science by Jesse Toth

  42. Single Points of Failure Case Study 2 An Identity Service

  43. 1. Manage complexity of User object. Project Goals:

  44. 1. Manage complexity of User object 2. Respect team ownership

    Project Goals:
  45. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  46. Main App Identity Service

  47. Main App Identity Service

  48. Main App Identity Service

  49. Star Wars Joke

  50. Main App Identity Service iOS app

  51. Main App Identity Service iOS app

  52. Main App Identity Service iOS app

  53. 1. Added operational complexity Failures:

  54. 1. Added operational complexity 2. Two single points of failure

    Failures:
  55. Star Wars Joke

  56. 1. Added operational complexity 2. Two single points of failure

    3. Slowed down every request Failures:
  57. Request Response Main App Time Request Queuing:

  58. Main App Time ID Service Request Queuing:

  59. Main App Time ID Service Request Queuing:

  60. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  61. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  62. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  63. class RepositoryController < ApplicationController areas_of_responsibility :repos … end class OrganizationsController

    < ApplicationController areas_of_responsibility :orgs, :abilities … end Team Responsibilities:
  64. Versioning & Updating Services Case Study 3 Building an Asset

    Service
  65. Monoliths have one copy of HTML CSS JS Images Best

    Star Wars Memes
  66. Service Service Service Service Best Star Wars Memes Best Star

    Wars Memes
  67. Service Service Service Service Best Star Wars Memes Best Star

    Wars Memes Best Star Wars Memes Best Star Wars
  68. Service Service Service Service Best Star Wars Memes Best Star

    Wars Memes Best Star Wars Memes Best Star Wars
  69. Avoid Repeating HTML, CSS, JS and Images across apps and

    services Project Goal:
  70. Service Service Service

  71. Service Service Service

  72. Service Service Service ′

  73. Best Star Best Star Best Star ′

  74. Best Star Best Star Best Star ′ ′ ′

  75. Star Wars Joke

  76. 1. Required uniformly redeploying several apps Failures:

  77. 1. Required uniformly redeploying several apps 2. Made it harder

    to change assets Failures:
  78. 1. Required uniformly redeploying several apps 2. Made it harder

    to change assets 3. Finding source code is tricky Failures:
  79. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  80. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  81. Service Service Service Asset Service

  82. Web Front End Build together what changes together: Native App

    Backend API
  83. Monolith

  84. Failing Gracefully Case Study 4 Social feature

  85. Best Star Wars Memes

  86. Best Star Wars Memes

  87. Don’t slow down core functionality Project Goal:

  88. Main App Identity Service

  89. Failures:

  90. 1. Make our product more resilient and fault tolerant. 2.

    Encourage understanding, debugging, and changing code. 3. Help teams work together. Architecture should:
  91. 1. We should use evidence 2. Criteria to look for

    3. Case Studies 4. Conclusions
  92. 1. Untangle code before trying to extract it How to

    SOA:
  93. 1. Untangle code before trying to extract it 2. Don’t

    create more single points of catastrophic failure How to SOA:
  94. 1. Untangle code before trying to extract it 2. Don’t

    create more single points of catastrophic failure 3. Build together the parts that will need to change togther How to SOA:
  95. non Star Wars Joke

  96. Sam Brown explodingdog.com amazing drawings by

  97. None
  98. @rachelmyers Happy to (civilly) argue or chat: