Modules instead of Microservies

Transcript

1. MODULES INSTEAD OF MICROSERVICES Benjamin Smith @benjamin_smith
2. @benjamin_smith
6. @benjamin_smith
8. MODULES INSTEAD OF MICROSERVICES @benjamin_smith
9. MODULES @benjamin_smith
10. MICROSERVICES @benjamin_smith
11. @benjamin_smith
12. MICROSERVICES @benjamin_smith
13. rails new my_shiny_new_app @benjamin_smith
15. phhhhfff! namespaces? forget about it @benjamin_smith
16. engines @benjamin_smith
17. Rails Engines Ruby Gems Java Modules Node Packages }MODULES
18. MODULES • Self contained • Clearly defined boundaries • Explicit dependencies @benjamin_smith
19. Rails Engines Ruby Gems Java Modules Node Packages }MODULES
20. MODULES • All code lives in the same repo • Modules define the boundaries and dependencies @benjamin_smith
22. @benjamin_smith
23. @benjamin_smith
29. MODULES @benjamin_smith
30. MICROSERVICES @benjamin_smith
31. MICROSERVICES • Scaling • Shared data/behavior across apps • Different services requiring different tech stacks • Feeling cool @benjamin_smith
32. your company’s best practices some other company’s best practices != @benjamin_smith
33. MODULES definitely use them @benjamin_smith
35. MICROSERVICES • Smaller, easier to manage, codebases • Scalable • Handling large teams @benjamin_smith
36. Smaller, easier to manage, codebases @benjamin_smith
38. Features Time @benjamin_smith
39. Features Time @benjamin_smith
42. @benjamin_smith
43. @benjamin_smith
46. MODULES @benjamin_smith
48. MODULES interfaces and API == functions and methods @benjamin_smith
49. Smaller, easier to manage, codebases @benjamin_smith
50. MODULES • Code • Data • Dependencies • Tests @benjamin_smith
52. Features Time @benjamin_smith
53. Scaling @benjamin_smith
54. How to create a service • Step 1: create a module • Step 2: create a service • Step 3: ??? • Step 4: profit @benjamin_smith
56. module to microservice class Likes def self.create(…) # create like in DB Like.create!(…) end end class Likes def self.create(…) # make request to Like service Net::HTTP.post_form(…) end end @benjamin_smith
58. Handling large teams @benjamin_smith
60. MICROSERVICES • Smaller, easier to manage, codebases • Scalable • Handling large teams @benjamin_smith
61. security @benjamin_smith
62. discovery @benjamin_smith
63. centralized logging and debugging @benjamin_smith
64. A centralized logging and debugging @benjamin_smith
65. A centralized logging and debugging B C @benjamin_smith
66. A centralized logging and debugging B C @benjamin_smith
67. API documentation @benjamin_smith
68. performance @benjamin_smith
69. Users Comments
70. Activities Users Comments
71. Activities Users Comments users comments
72. Activities Users Comments create table users create table comments comments users
73. Activities Users Comments create table users create table comments comments users …
74. @benjamin_smith
75. transactions @benjamin_smith
76. testing @benjamin_smith
77. I could go on… @benjamin_smith
78. MODULES INSTEAD OF MICROSERVICES @benjamin_smith
79. Note: modules are hard @benjamin_smith
80. The End? @benjamin_smith
81. MODULES @benjamin_smith
82. MONOLITH INSTEAD OF MODULES @benjamin_smith
83. MONOLITH @benjamin_smith
84. MODULES @benjamin_smith
87. –Martin Fowler “So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don't try to separate it into separate services.”
88. MONOLITH @benjamin_smith
89. MONOLITH MODULES @benjamin_smith
90. MONOLITH MODULES MICROSERVICES @benjamin_smith
91. Thanks! @benjamin_smith Additional Resources: Rails: cbra.info Java: appcontinuum.io Node: github.com/c9/architect ?
92. Questions? @benjamin_smith Additional Resources: Rails: cbra.info Java: appcontinuum.io Node: github.com/c9/architect ?