Successfully reported this slideshow.

I-Tier: Breaking Up the Monolith @ Philly ETE

2,025 views

Published on

Groupon recently completed a year-long project to migrate its U.S. web traffic from a monolithic Ruby on Rails application to a new multi-application stack with substantial results.

Groupon’s entire U.S. web frontend had been a single Rails codebase from its inception in 2008. The frontend codebase quickly grew large, which made it difficult to maintain and challenging to ship new
features. As a solution to this gigantic monolith, we decided to re-architect the frontend by splitting it into small, independent and more manageable pieces. At the center of this project, we rebuilt each
major section of the website as an independent application. We also rebuilt the infrastructure to make all the independent apps work together. Interaction Tier (I-Tier) was the result.

Learn about how Groupon achieved this great architecture migration and the business results it is driving.

Published in: Engineering, Technology

I-Tier: Breaking Up the Monolith @ Philly ETE

  1. 1. i-tier: breaking up the monolith sean mccullough groupon engineering @mcculloughsean
  2. 2. this presentation is about 4 how Groupon's software stopped working 4 how we rewrote a part of it 4 what went well and what didn't
  3. 3. this presentation isn't about 4 node.js 4 javascript
  4. 4. Problems
  5. 5. simple start 4 monolithic Ruby on Rails app 4 sustained business through hypergrowth 4 small engineering team 4 simple product
  6. 6. acquisitions 4 CityDeal.de (Germany, most of EU) 4 SoSata (India) 4 Needish (South America) ran as separate platforms
  7. 7. new products 4 Goods 4 Getaways 4 Reserve
  8. 8. improvements 4 Smart Deals 4 Browse and Search 4 Rocketman
  9. 9. one monolithic application
  10. 10. actually, two separate monoliths
  11. 11. move to mobile 4 ~50% of global transactions 4 streamlined user experience 4 mobile uses REST API
  12. 12. two facets of the same monolith
  13. 13. two facets X two monoliths
  14. 14. business was stuck 4 could not build features fast enough 4 wanted to build features worldwide 4 mobile and web lacked feature parity 4 could not change look and feel
  15. 15. The Plan
  16. 16. start with the frontend 4 unify global look and feel 4 REST API already built for mobile 4 backend services are more complicated to unite
  17. 17. design goals 4 decouple teams 4 deploy apps on team schedule 4 allow for global design changes 4 I18n/L13n 4 be small, do the minimum
  18. 18. bakeoff 4 Node 4 MRI Ruby/Rails, MRI Ruby/Sinatra 4 JRuby/Rails, Sinatra 4 MRI Ruby + Sinatra+EM 4 Java/Play, Java/Vertx 4 Python+Twisted 4 PHP
  19. 19. why node 4 vibrant community 4 NPM! 4 frontend developers know javascript 4 performant enough 4 easy scaling (process model)
  20. 20. simple design main: ( {attributes, renderCallback} ) -> # Presenter that sets the layout view = presenters.page 'subscribe', attributes # Grab the list of all the divisions grouponAPI.fetch { endpoint: 'divisions' }, (err, {divisions}, details) -> # If there’s an error, bail and pass the error along return renderCallback err if err? divisionsPresenter = presenters.divisions divisions, { currentDivision: attributes.query?.division_p } view.set { divisions: divisionsPresenter } render.pageHtml view, renderCallback
  21. 21. boundaries 4 apps only talk to api and memcached 4 layout is in a separate application 4 shared common asset bundle
  22. 22. growing pains 4 max sockets 4 breaking our infrastructure
  23. 23. subscribe page 4 simple application 4 partial implementation 4 proved out the concept
  24. 24. new problems 4 user authentication 4 more service calls 4 complicated routing 4 more traffic 4 share look and feel
  25. 25. Part III - Architecture
  26. 26. grout switchboard for incoming requests to I- Tier applications
  27. 27. grout Route on: 4 domain 4 locale 4 country 4 experiments
  28. 28. grout 4 groupon.com/deals/my-awesome-deal 4 itier-deal-page-vip.snc1/deals/my- awesome-deal 4 groupon.de/browse/berlin 4 itier-browse-page-vip.lup1/browse/ berlin
  29. 29. grout 4 experiments between different applications on the same URL 4 testing between alternative implementations (including the legacy monoliths!)
  30. 30. gconfig configuration as a service some config can change on the fly config can be promoted from uat -> staging -> prod
  31. 31. layout service maintain consistent look and feel across site
  32. 32. layout service options 4 distribute layout as library 4 use ESIs for top/bottom of page 4 apps are called through a “chrome service” 4 fetch templates from service
  33. 33. layout service chose a service 4 independent rollouts 4 changes can be shipped without redploying all apps 4 easy to use in development
  34. 34. layout service 4 Uses semantic versioning 4 Roll forward with bug fixes 4 Stay locked on a specific version 4 Enable Site-Wide Experiments
  35. 35. Rewrite All The Things!
  36. 36. rewrite 4 get the whole company to move at once 4 upporting two platforms is hard 4 as of June 2012 - move to I-Tier by September 1st
  37. 37. rewrite 4 ~150 developers 4 global effort 4 feature freeze – A/B testing against mostly the same features
  38. 38. it worked!
  39. 39. webpages got faster
  40. 40. sustained record traffic
  41. 41. what doesn't work 4 increased testing burden 4 tooling needs to catch up 4 increased operational overhead
  42. 42. culture problems 4 changed team workflow 4 teams are silos 4 code quality varies
  43. 43. next steps 4 streaming responses for better performance 4 better resiliency to outages 4 distributed tracing 4 international (launching today!) 4 open source - testium
  44. 44. tl;dr 4 monolith 4 federated frontend 4 service oriented architecture 4 grout 4 gconfig 4 layout service
  45. 45. thanks! sean mccullough groupon engineering @mcculloughsean

×