Architecture: The Next Generation - Railsconf 2017

Architecture: The Next Generation - Railsconf 2017

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

A48e4c63da24c13c870f9b3ef7f8f86f?s=128

Taylor Jones

April 27, 2017
Tweet

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
  4. None
  5. None
  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
  115. None
  116. None
  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