Service Oriented Disasters

Deck from RubyConfAu 2015

Transcript

1. Service Oriented Disasters Ruby Conf Au 2015 @rachelmyers
2. RailsBridge
3. RailsBridge BridgeFoundry
4. Patchwork RailsBridge BridgeFoundry
5. bit.ly/ service oriented disasters
7. 1. Complexity is a problem for everyone.
8. 1. Complexity is a problem for everyone. 2. Architecture decisions hugely impact code complexity.
10. 1. Make each class and method conceptually simple.
11. 1. Make each class and method conceptually simple. 2. Reduce complexity in major code paths and in code that changes often.
12. 2. Reduce complexity in major code paths and in code that changes often. 3. Complexity in stable code paths is probably acceptable. 1. Make each class and method conceptually simple.
13. 2. Reduce complexity in major code paths and in code that changes often. 3. Complexity in stable code paths is more acceptable. 1. Make each class and method conceptually simple.
18. hatsforspacedogs.com
19. Case Study 1: Extracting Tangled Code
20. the javascript
21. # This class encapsulates behavior for hats that are actually for sale as well as hat samples we might sell. class Hat # Public: Adds a Hat to a Cart # Returns the Hat. def add_to(cart) … end # Public: Vote for a sample Hat # Returns True. def vote_yes(user) … end end the ruby
22. # This class encapsulates behavior for hats that are actually 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 def vote_yes(user) … end end
23. # This class encapsulates behavior for hats that are actually 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 def vote_yes(user) … end end
24. Problems to solve: 1. Follow Single Responsibility Principle
25. 2. Solve “Unrefactorable” javascript Problems to solve: 1. Follow Single Responsibility Principle
28. Main DB Mini DB
29. Main DB Mini DB
30. Main DB Mini DB
31. Main DB Mini DB Gem Server
32. 1. We drew the wrong lines around services. Failures:
33. 2. We didn’t manage our complexity; we reinforced it. 1. We drew the wrong lines around services. Failures:
34. github.com/github/scientist
35. “Easy Rewrites with Ruby and Science” By Jesse Toth
36. Case Study 2: An Identity Service
37. Problems to solve: 1. Manage SpaceDog complexity a.k.a. User
38. Problems to solve: 1. Manage SpaceDog complexity 2. Allow one team to own the model
45. 1. Added risk & operational complexity. Failures:
46. 2. Didn’t simplify anything. 1. Added risk & operational complexity. Failures:
48. Queueing Theory! Request Response Time spent in Main App Time Request Response Time in Identity Service
49. Queueing Theory! Request Response Time spent doing everything Time
50. Defined Team Responsibilities
51. Case Study 3: Sharing Assets Across Applications
52. hatsforspacedogs.com helmets galea fedoras diving-bells
53. hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells
54. Shared HTML, CSS, JS & Images hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells
55. Problems to solve: 1. Avoid repeating HTML, CSS, JS and images across applications.
59. hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells
60. hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells hatsforspacedogs.com helmets galea fedoras diving-bells
61. 1. Required coordinated upgrades & deployments. Failures:
62. Problems to solve: 1. Avoid repeating HTML, CSS, JS and images across applications. 2. Asset changes should update at the same time.
64. GitHub hides this problem.
65. Conclusions
66. 1. SOA works for good code, isolated classes with well-defined boundaries Conclusions
67. Conclusions 1. SOA works for good code. 2. SOA works when code needs to run in multiple places.
68. Conclusions 2. SOA works when it needs to run in multiple places. 3. SOA works when it doesn’t create a bottleneck for the main app. 1. SOA works for good code.
70. Sam Brown explodingdog.com amazing drawings by (via @kcshearon!)
71. Sam Brown explodingdog.com skirts (and architecture diagrams) by me amazing drawings by (via @kcshearon!)
72. bit.ly/ service oriented disasters @rachelmyers