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. 3.

    HI. MY NAME IS TAYLOR JONES. @HIIMTAYLORJONES YOU CAN FIND

    ME ON THE INTERNET UNDER @HIIMTAYLORJONES
  2. 4.
  3. 5.
  4. 6.

    AN INTRODUCTION SO WHAT DO I ACTUALLY DO? @HIIMTAYLORJONES I

    Write Things on the Internet @codeship hiimtaylorjones.com @hiimtaylorjones
  5. 10.

    AN INTRODUCTION WHAT EXACTLY DOES IZEA DO? @HIIMTAYLORJONES Content Marketing

    Social Media Analytics General Data Analytics Enterprise Marketing Systems
  6. 11.

    IZEA HAS A GROWING MOUNTAIN OF DATA TO SORT THROUGH

    @HIIMTAYLORJONES HONESTLY, WE ALL DO.
  7. 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
  8. 16.
  9. 19.

    ARCHITECTURE IS THE ROOT OF A LOT OF OUR TECHNICAL

    DEBT @HIIMTAYLORJONES I BELIEVE
  10. 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
  11. 21.

    HAVE THINGS ALWAYS BEEN THIS WAY? @HIIMTAYLORJONES DOES MODERN ARCHITECTURE

    HAVE MORE DEBT? DID WE LOSE SOMETHING ALONG THE WAY?
  12. 22.

    THE PAST LETS LOOK BACK FOR A MOMENT AT MAYBE

    WE CAN FIND SOMETHING WITHIN IT
  13. 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
  14. 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.
  15. 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
  16. 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.
  17. 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.
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 48.

    IN SHORT, THEY BROKE DOWN SOMETHING BIGGER INTO UNIQUE SERVICES

    THAT WORK TOGETHER @HIIMTAYLORJONES THIS SOUNDS FAMILIAR
  24. 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?
  25. 55.

    NETFLIX CREATED NEW TESTING STANDARDS IN ORDER TO PROPERLY EXERCISE

    THEIR SUITE OF MICRO SERVICES @HIIMTAYLORJONES
  26. 58.

    WE TRADE THE COMFORT OF UNDERSTANDING FOR THE PROMISE OF

    HAPPIER DEVELOPMENT @HIIMTAYLORJONES
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. 92.

    OK. I SEE WHAT YOU’RE SAYING BUT WE REALLY WANT

    TO SWITCH ARCHITECTURE BECAUSE REASONS @HIIMTAYLORJONES
  35. 94.

    LETS SAY YOU WANT OUT OF YOUR CURRENT ARCHITECTURE? @HIIMTAYLORJONES

    HOW SHOULD WE APPROACH A SITUATION LIKE THIS?
  36. 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
  37. 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
  38. 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
  39. 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
  40. 109.

    HOW SHOULD I IMPLEMENT THIS KIND OF STUFF IN A

    TEAM ENVIRONMENT? @HIIMTAYLORJONES
  41. 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
  42. 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
  43. 113.

    STORY OF MY LIFE EDITION ALRIGHT, LETS WRAP IT UP

    DUDE. YOU’VE BEEN TALKING FOR LIKE FOREVER
  44. 114.

    ARCHITECTURE IS A HOUSE @HIIMTAYLORJONES DEBT PILES UP IN DIFFERENT

    PLACES DEPENDING ON WHAT KIND OF ARCHITECTURE WE UTILIZE
  45. 115.
  46. 116.
  47. 117.

    ARCHITECTURE IS AN ESCAPE HATCH @HIIMTAYLORJONES SOMETIMES, ITS NECESSARY OR

    EASIER TO ESCAPE DEBT BY SWITCHING TO A NEW “HOUSE”
  48. 118.

    ARCHITECTURE IS A HOUSE @HIIMTAYLORJONES ULTIMATELY, WE NEED TO LEARN

    HOW TO PROPERLY CLEAN AND MAINTAIN OUR HOUSE. MOVING IS EXPENSIVE.
  49. 119.

    CONFRONT TECHNICAL DEBT @HIIMTAYLORJONES FIND A PLACE IN YOUR PROCESS

    THAT ALLOWS FOR ADDRESSING DEBT WHILE PUSHING FORWARD FEATURES.
  50. 120.

    CONFRONT TECHNICAL DEBT @HIIMTAYLORJONES IT MIGHT TAKE LONGER BUT IT’LL

    ULTIMATELY DELIVER CLEANER & MORE STABLE FEATURES TO YOUR CUSTOMERS