Architecture: The Next Generation - Railsconf 2017

Talking about the Past, Present, and Future of Rails Architecture.

Transcript

1. HI. @HIIMTAYLORJONES
2. ARCHITECTURE THE NEXT GENERATION THIS TALK IS CALLED: @HIIMTAYLORJONES
3. HI. MY NAME IS TAYLOR JONES. @HIIMTAYLORJONES YOU CAN FIND ME ON THE INTERNET UNDER @HIIMTAYLORJONES
6. AN INTRODUCTION SO WHAT DO I ACTUALLY DO? @HIIMTAYLORJONES I Write Things on the Internet @codeship hiimtaylorjones.com @hiimtaylorjones
7. STAR TREK @HIIMTAYLORJONES THIS TALK ISN'T REALLY ABOUT OR WHICH ENTERPRISE SHIP IS THE BEST
8. SORRY @HIIMTAYLORJONES
9. AN INTRODUCTION SO WHO DO YOU ACTUALLY WORK FOR? @HIIMTAYLORJONES
10. AN INTRODUCTION WHAT EXACTLY DOES IZEA DO? @HIIMTAYLORJONES Content Marketing Social Media Analytics General Data Analytics Enterprise Marketing Systems
11. IZEA HAS A GROWING MOUNTAIN OF DATA TO SORT THROUGH @HIIMTAYLORJONES HONESTLY, WE ALL DO.
12. IZEA’S BUSINESS DEPENDS ON A LOT OF EXTERNAL APIS AND SUCH @HIIMTAYLORJONES
13. AN INTRODUCTION WHAT TOOLS DOES IZEA USE? @HIIMTAYLORJONES A Whole Lot of Rails A Whole Lot of EmberJS A Good Bit of Java A Decent Amount of Python
14. THE BALANCE OF LANGUAGES IN IZEA’S STACK IS ALWAYS CHANGING @HIIMTAYLORJONES
15. RAILS ARCHITECTURE @HIIMTAYLORJONES THIS TALK IS MOSTLY ABOUT WHERE ITS BEEN AND WHERE ITS GOING
16. TECHNICAL DEBT. @HIIMTAYLORJONES THIS TALK IS ALSO ABOUT AND HOW ARCHITECTURE CAN CREATE OR RELIEVE IT
17. IZEA HAS TECHNICAL DEBT @HIIMTAYLORJONES
18. HAS TECHNICAL DEBT @HIIMTAYLORJONES YOUR COMPANY
19. ARCHITECTURE IS THE ROOT OF A LOT OF OUR TECHNICAL DEBT @HIIMTAYLORJONES I BELIEVE
20. HOW EXACTLY DOES ARCHITECTURE CREATE TECHNICAL DEBT? @HIIMTAYLORJONES WE OFTEN BECOME SO FOCUSED ON BUILDING STUFF, THAT WE FORGET TO CLEAN UP OUR MESS. FIXING TECHNICAL DEBT IS OFTEN VIEWED AS A SECONDARY FOCUS. AFTER ALL, FEATURES MAKE MONEY
21. HAVE THINGS ALWAYS BEEN THIS WAY? @HIIMTAYLORJONES DOES MODERN ARCHITECTURE HAVE MORE DEBT? DID WE LOSE SOMETHING ALONG THE WAY?
22. THE PAST LETS LOOK BACK FOR A MOMENT AT MAYBE WE CAN FIND SOMETHING WITHIN IT
23. WHAT WAS EARLY WEB DEVELOPMENT LIKE? @HIIMTAYLORJONES Applications Were Hard To Deploy Code Organization Was Inconsistent License-Driven Development Environments were hard to Duplicate
24. BUT THEN A NEW CONTENDER APPEARED WHAT COULD IT BE?
25. CONVENTION OVER CONFIGURATION @HIIMTAYLORJONES What does it mean? Rails employs this idea of Why does it matter?
26. RAILS TOOK THE WEB DEVELOPMENT PROCESS AND REFACTORED IT. @HIIMTAYLORJONES
27. REFACTORS AREN’T AUTOMATICALLY GOOD BY NATURE @HIIMTAYLORJONES
28. WHAT KIND OF REFACTOR IS RAILS? @HIIMTAYLORJONES SO,
29. HOW HAS RAILS EVOLVED? This is a kitten. !
30. SOME PERSPECTIVE - THE DEVELOPMENT OF RAILS THE ORIGIN OF RAILS @HIIMTAYLORJONES Based on an extraction of existing product. Its creation was rooted in a real-world use case. Eventually found its home as an open-source project.
31. SOME PERSPECTIVE - THE DEVELOPMENT OF RAILS MERB @HIIMTAYLORJONES MERB was a reaction to the problems in Rails “Clean Room” implementation Speed Scalability Modularity API Tools
32. SOME PERSPECTIVE - THE DEVELOPMENT OF RAILS MERB + RAILS @HIIMTAYLORJONES Rails and Merb decided to work together. This was pitched as a good thing for Ruby on the Web? In short, I believe it worked out really well. Some ideas didn’t quite survive the merger.
33. POST- MERGER RAILS @HIIMTAYLORJONES
34. ARCHITECTURE BEGINS TO BECOME SLOW, MESSY, AND A PAIN TO MAINTAIN AFTER TIME, @HIIMTAYLORJONES RECOGNIZING CODE SMELLS, BAD PATTERNS, AND OTHER HARMFUL THINGS ISN’T EASY.
35. WHAT KILLED SMALLTALK WAS THAT IT WAS EASY TO MAKE A MESS Robert C. Martin (Quoting Ward Cunningham) - RailsConf 2010 SOME PERSPECTIVE - HOW RAILS HAS EVOLVED @HIIMTAYLORJONES
36. SOME PERSPECTIVE - HOW HAS RAILS EVOLVED HOW TO MAKE A MESS IN RAILS ▸ Lack of distribution between Model, View, and Controller layer ▸ Misunderstanding Rails Queries - The N+1 Problem ▸ Misunderstanding Ruby’s API ▸ Common code smells @HIIMTAYLORJONES
37. IT BEGAN TO ADDRESS THE ISSUES THAT PLAGUED THE COMMUNITY THE MOST AS RAILS GREW, @HIIMTAYLORJONES THIS INVOLVED MAKING THE FRAMEWORK MORE MODULAR, EFFICIENT, AND SCALABLE
38. IS RAILS AS USEFUL AS IT ONCE WAS? @HIIMTAYLORJONES
39. IS RAILS AS RELEVANT AS IT ONCE WAS? @HIIMTAYLORJONES
40. IS RAILS FINISHED? @HIIMTAYLORJONES
41. SHOULD WE ALL JUST GO HOME AND START USING SOMETHING ELSE? @HIIMTAYLORJONES
42. @HIIMTAYLORJONES
43. AND THE CASE FOR SWITCHING AWAY FROM RAILS TWITTER
44. TWITTER SUDDENLY BECAME A REALLY BIG DEAL. @HIIMTAYLORJONES
45. LESSONS FROM THE PAST - TWITTER THE BIRTH OF TWITTER ▸ When the product was initially created, it was written in Rails. ▸ Twitter, for a moment, became this poster child for Rails in popular culture. ▸ Then, rumors started to emerge that their Engineering team was starting to shift away from their Rails stack. @HIIMTAYLORJONES
46. WHY DID TWITTER START MOVING AWAY FROM RAILS? @HIIMTAYLORJONES
47. LESSONS FROM THE PAST - TWITTER A PROBLEM OF REINVENTING SEARCH ▸ When Twitter was rewriting their search service, they found some frustrations with their tech stack, Specifically Rails. ▸ Instead of trying to better leverage Rails / Ruby for the task, they decided to build it from the ground up with Scala. ▸ Twitter has a lot of data to store and comb through ▸ The easiest way to escape tech debt is rewriting from scratch. ▸ Twitter gradually dismantled their Rails instance and wrote their own iterations of those services. @HIIMTAYLORJONES
48. IN SHORT, THEY BROKE DOWN SOMETHING BIGGER INTO UNIQUE SERVICES THAT WORK TOGETHER @HIIMTAYLORJONES THIS SOUNDS FAMILIAR
49. MICROSERVICES @HIIMTAYLORJONES ALL ABOARD THE HYPE TRAIN
50. HOW HAVE MICROSERVICES BENEFITED OTHER COMPANIES? @HIIMTAYLORJONES WHAT’S THE BIG DEAL?
51. ALL-IN ON MICROSERVICES @HIIMTAYLORJONES
52. NETFLIX IS A REALLY PREVALENT SUCCESS STORY AND ADVOCATE FOR MICROSERVICES @HIIMTAYLORJONES
53. @HIIMTAYLORJONES LESSONS FROM THE PAST - NETFLIX ▸ Netflix took an early bet on Microservices. Its worked out pretty well for them so far. ▸ Frees developers to create new features in whatever language they want. NETFLIX HAS REALLY GOOD ARCHITECTURE HOW DO YOU TEST THIS KIND OF STUFF?
54. NETFLIX’S SIMIAN ARMY
55. NETFLIX CREATED NEW TESTING STANDARDS IN ORDER TO PROPERLY EXERCISE THEIR SUITE OF MICRO SERVICES @HIIMTAYLORJONES
56. THE SIMIAN ARMY CREATES INCREDIBLY HIGH STAKES FOR DEVELOPERS @HIIMTAYLORJONES
57. WHEN WE CHANGE ARCHITECTURES OUR PROCESS HAS TO CHANGE @HIIMTAYLORJONES THE TAKEAWAY:
58. WE TRADE THE COMFORT OF UNDERSTANDING FOR THE PROMISE OF HAPPIER DEVELOPMENT @HIIMTAYLORJONES
59. EVERY ARCHITECTURE IS A BRAVE NEW WORLD! @HIIMTAYLORJONES
60. HOW DO THESE SUCCESS STORIES AND LESSONS RELATE TO RAILS ARCHITECTURE? @HIIMTAYLORJONES
61. DESIGNING ARCHITECTURE WITH RAILS LET’S TALK ABOUT RAILSCONF EDITION
62. MONOLITHIC DESIGN @HIIMTAYLORJONES
63. MONOLITHIC DESIGN WHAT EXACTLY IS A MONOLITH? @HIIMTAYLORJONES Views Middleware Models Database
64. MONOLITHIC DESIGN WHAT’S THE DEAL WITH MONOLITHS ▸ Rails historically has skewed towards a Monolithic tendency. ▸ This tendency has served the framework well ▸ It has also been the subject of a lot of hate mail ▸ “The Majestic Monolith” @HIIMTAYLORJONES
65. MONOLITHS ARE ROOTED IN UNIFORMITY @HIIMTAYLORJONES
66. MONOLITHS ARE ROOTED IN VERY TIGHT COUPLING @HIIMTAYLORJONES
67. IZEA AND MONOLITHIC ARCHITECTURE @HIIMTAYLORJONES
68. MONOLITHIC DESIGN HOW IZEA HANDLES MONOLITHIC APPLICATIONS ▸ We learned the hard way about how jobs should be balanced and queued properly ▸ We also realized the need for a greater means of queued processing. ▸ To accomplish this, we started leveraging things like AWS Lambda’s alongside other smaller services ▸ In short, we started to dabble in Microservices @HIIMTAYLORJONES
69. MICROSERVICE DESIGN @HIIMTAYLORJONES MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE MICORSERVICE
70. MICROSERVICE DESIGN REMEMBER MONOLITHS? @HIIMTAYLORJONES Views Middleware Models Database
71. MICROSERVICE DESIGN THESE ARE MICROSERVICES @HIIMTAYLORJONES Views Models Database Middleware
72. MICROSERVICE DESIGN NATURALLY LOOKS CLEANER @HIIMTAYLORJONES
73. MICROSERVICE DESIGN HOW DOES MICROSERVICE DESIGN WITH RAILS WORK? ▸ The most popular implementation is Rails as an API ▸ The API utility of Rails is largely due to the rise of front- end frameworks and popularity of Mobile Applications ▸ There are certainly use cases for extracting the view layer and middleware for other cases. @HIIMTAYLORJONES
74. MICROSERVICE DESIGN HOW IZEA HANDLES MICROSERVICE APPLICATIONS ▸ AWS is a powerful ally for us ▸ We create services that help us delegate heavier system tasks ▸ We leverage diverse, but stable languages for this ▸ Java ▸ Python ▸ SQL @HIIMTAYLORJONES
75. MICROSERVICE DESIGN HOW IZEA HANDLES MICROSERVICE APPLICATIONS ▸ Stable languages are incredibly important ▸ Ultimately, you want to be able to hire developers that can easily maintain and improve your applications. ▸ Newer languages eventually need to be proven by someone. However, taking smaller risks is important. @HIIMTAYLORJONES
76. MICROSERVICES ARE ROOTED IN MODULARITY @HIIMTAYLORJONES
77. MICROSERVICES ARE ROOTED IN LOOSE COUPLING @HIIMTAYLORJONES
78. MICROSERVICE ECOSYSTEMS @HIIMTAYLORJONES
79. MICROSERVICE ECOSYSTEM DESIGN REMEMBER MONOLITHS? @HIIMTAYLORJONES Views Middleware Models Database
80. MICROSERVICE ECOSYSTEM DESIGN REMEMBER MICROSERVICES? @HIIMTAYLORJONES Views Models Database Middleware
81. MICROSERVICE ECOSYSTEM DESIGN THIS IS A MICROSERVICE ECOSYSTEM @HIIMTAYLORJONES Views Middleware Models Database
82. MICROSERVICE ECOSYSTEMS ARE ROOTED IN MODULARITY @HIIMTAYLORJONES
83. MICROSERVICE ECOSYSTEMS ARE ROOTED IN TIGHTER COUPLING @HIIMTAYLORJONES
84. MOST OF OUR APPLICATIONS EXIST WITHIN THIS SPACE @HIIMTAYLORJONES
85. @HIIMTAYLORJONES
86. MICROSERVICE ECOSYSTEMS - DOCKER DOCKER IS A MICROSERVICE ECOSYSTEM ▸ You can create smaller docker containers of any configuration of your choosing. ▸ For best performance, you dockerize each part of your ecosystem and then wrap that within a Docker container. ▸ You then have a means to orchestrate your entire ecosystem and a common language for all the components to talk with. @HIIMTAYLORJONES
87. @HIIMTAYLORJONES
88. MICROSERVICE ECOSYSTEMS - AMAZON WEB SERVICES AWS IS A MICROSERVICE ECOSYSTEM ▸ You have all of these services built in different languages and stacks. ▸ Depending on how a user’s service is set up, certain elements of those services are coordinated by AWS. ▸ AWS is an ecosystem. Their services are Microservices. @HIIMTAYLORJONES
89. @HIIMTAYLORJONES
90. CAN RAILS FACILITATE A SYSTEM OF MICOSERVICES? @HIIMTAYLORJONES
91. IN MANY WAYS, RAILS IS A MICROSERVICE ECOSYSTEM. @HIIMTAYLORJONES
92. OK. I SEE WHAT YOU’RE SAYING BUT WE REALLY WANT TO SWITCH ARCHITECTURE BECAUSE REASONS @HIIMTAYLORJONES
93. ONE ARCHITECTURE DOES NOT FIT ALL RAILS APPS @HIIMTAYLORJONES AFTER ALL,
94. LETS SAY YOU WANT OUT OF YOUR CURRENT ARCHITECTURE? @HIIMTAYLORJONES HOW SHOULD WE APPROACH A SITUATION LIKE THIS?
95. RAILS EDITION HOW TO SWITCH ARCHITECTURE WITHOUT CRUSHING YOUR HOPES AND DREAMS
96. KILL THE HYPE. @HIIMTAYLORJONES First,
97. MIGRATING TO A NEW ARCHITECTURE - KILL THE HYPE KILL THE HYPE ▸ We’re prone to exalt shiny new things. ▸ Innovation and new ideas are really exciting! ▸ There’s a difference between implementing something in a side project and converting an entire production- app to a new architecture. ▸ Younger != Better @HIIMTAYLORJONES
98. RESET YOUR BIAS. THINGS HAVE CHANGED. @HIIMTAYLORJONES
99. MIGRATING TO A NEW ARCHITECTURE - KILL THE HYPE KILL THE HYPE ▸ What you’re doing is working just fine. ▸ Every method has a balance that’s required of developers. ▸ Think about what kind of architecture best supports your team size and skillsets. @HIIMTAYLORJONES
100. FIND YOUR PACING. @HIIMTAYLORJONES secondly,
101. MIGRATING TO A NEW ARCHITECTURE - FIND YOUR PACING FIND YOUR PACING ▸ We talk a lot about the concept of DevOps ▸ DevOps matters a lot in your architecture ▸ Your development process matters even more ▸ The cadence by which your team goes, determines what kind of architectures you can best implement. @HIIMTAYLORJONES
102. KNOWLEDGE IS POWER @HIIMTAYLORJONES finally,
103. THERE IS AN INEQUALITY OF KNOWLEDGE IN PROGRAMMING @HIIMTAYLORJONES
104. KNOWLEDGE IS POWER - SHARING THE WEALTH THERE’S AN INEQUALITY IN SOFTWARE DESIGN KNOWLEDGE ▸ We often only let the “Professionals” discuss, design, and improve architecture. ▸ What happens when those people retire, quit, move on? ▸ How do we train new developers in the ways of software design? @HIIMTAYLORJONES
105. WE ALL COME FROM DIFFERENT PLACES AND BACKGROUNDS. @HIIMTAYLORJONES
106. CODING BOOTCAMPS @HIIMTAYLORJONES FORMAL EDUCATION SELF-TAUGHT
107. EMBRACE YOUR HISTORY. OWN IT. IMPLEMENT IT IN YOUR WORK. @HIIMTAYLORJONES
108. DON’T LET ANYONE SHAME YOU ABOUT YOUR PAST @HIIMTAYLORJONES
109. HOW SHOULD I IMPLEMENT THIS KIND OF STUFF IN A TEAM ENVIRONMENT? @HIIMTAYLORJONES
110. KNOWLEDGE IS POWER - SHARING THE WEALTH IMPLEMENTING IT IN A TEAM SETTING 1.Design with yourself or a small core team 2.Bring the proposed design to a small, but diverse group of Engineers. 3.Go back and make edits with your core team. 4.Bring the edited design to your whole engineering team and explain it. Ask for questions, feedback, and clarification. 5.Workshop it once more. 6.Go back to the whole Engineering team for a final presentation. @HIIMTAYLORJONES
111. CORE Workshop Whole Engineering Team 4, 6 1, 3, 5 2 Charts and Stuff
112. KNOWLEDGE IS POWER - SHARING THE WEALTH THERE’S AN INEQUALITY IN SOFTWARE DESIGN KNOWLEDGE ▸ Effective Software teams teach each other ▸ Effective Software Developers have the desire to learn. ▸ Some teams only have a select few of these attributes. ▸ This disconnect is creating developers who are uncomfortable outside their own company zone. @HIIMTAYLORJONES
113. STORY OF MY LIFE EDITION ALRIGHT, LETS WRAP IT UP DUDE. YOU’VE BEEN TALKING FOR LIKE FOREVER
114. ARCHITECTURE IS A HOUSE @HIIMTAYLORJONES DEBT PILES UP IN DIFFERENT PLACES DEPENDING ON WHAT KIND OF ARCHITECTURE WE UTILIZE
117. ARCHITECTURE IS AN ESCAPE HATCH @HIIMTAYLORJONES SOMETIMES, ITS NECESSARY OR EASIER TO ESCAPE DEBT BY SWITCHING TO A NEW “HOUSE”
118. ARCHITECTURE IS A HOUSE @HIIMTAYLORJONES ULTIMATELY, WE NEED TO LEARN HOW TO PROPERLY CLEAN AND MAINTAIN OUR HOUSE. MOVING IS EXPENSIVE.
119. CONFRONT TECHNICAL DEBT @HIIMTAYLORJONES FIND A PLACE IN YOUR PROCESS THAT ALLOWS FOR ADDRESSING DEBT WHILE PUSHING FORWARD FEATURES.
120. CONFRONT TECHNICAL DEBT @HIIMTAYLORJONES IT MIGHT TAKE LONGER BUT IT’LL ULTIMATELY DELIVER CLEANER & MORE STABLE FEATURES TO YOUR CUSTOMERS
121. CONFRONT TECHNICAL DEBT @HIIMTAYLORJONES ARCHITECTURE SHOULD FEEL COMFORTABLE. ITS AIM IS ULTIMATELY DEVELOPER HAPPINESS.
122. WHAT IS COMING FOR US NEXT? @HIIMTAYLORJONES
123. I HAVEN’T THE SLIGHTEST IDEA. @HIIMTAYLORJONES
124. MAYBE THINGS WILL BECOME MORE MODULAR. @HIIMTAYLORJONES
125. MAYBE THINGS WILL BECOME MORE MONOLOTHIC. @HIIMTAYLORJONES
126. MAYBE WEB ASSEMBLY IS GOING TO MESS OUR ENTIRE WORLD UP! @HIIMTAYLORJONES
127. THAT’S OK. @HIIMTAYLORJONES WE’RE READY FOR WHATEVER IS NEXT.
128. THANK YOU! @HIIMTAYLORJONES