Transitioning Groupon to Node.js - EmpireJS 2014
7 likes3,992 views
Groupon's monolithic platform was struggling to support growth and feature development. They rewrote part of it using a Node.js service-oriented architecture with decoupled frontend applications and shared backend services. This allowed for faster development and improved performance, but also introduced increased testing needs and operational complexity compared to the monolithic approach.
Transitioning Groupon to Node.js - EmpireJS 2014
- 1. I-Tier: Node.js at Groupon Sean McCullough @mcculloughsean Enterprise Node.js Developer at Groupon
- 2. This Presentation is About... • how Groupon's platform stopped working • how we rewrote a part of it • what went well and what didn't
- 3. Problems
- 4. Simple Start • Monolithic Ruby on Rails app • Sustained business through hyper-growth • Small engineering team • Simple product
- 5. Acquisitions • CityDeal.de (Germany, most of EU) • SoSata (India) • Needish (South America) Ran as separate platforms
- 7. Actually, two separate monoliths
- 8. Move to Mobile • ~50% of global transactions • Streamlined user experience • Mobile uses REST API
- 9. Two Facets of the Same Monolith
- 10. Two Facets X Two Monoliths
- 11. Business was Stuck • Could not build features fast enough • Wanted to build features worldwide • Mobile and web lacked feature parity • Could not change look and feel • Difficult to internationalize
- 12. Platform was Broken • Required cdn cached deal page • Monolith was hard to scale • Entire site would go down • Couldn't support growth
- 13. The Plan
- 14. Start with the Frontend • Unify global look and feel • REST API already built for mobile • Backend services are more complicated to unite
- 15. Design Goals • Decouple teams • Deploy apps on team schedule • Allow for global design changes • I18n/L13n • Be small, do the minimum
- 18. Bakeoff • Node • MRI Ruby/Rails, MRI Ruby/Sinatra • JRuby/Rails, Sinatra • MRI Ruby + Sinatra + EM • Java/Play, Java/Vertx • Python+Twisted • PHP
- 19. Why Node.js? • Vibrant community • NPM! • Frontend developers know javascript • Performant enough • Easy scaling (process model)
- 20. Why Node.js Javascript? • Front-end devs know Javascript • Leverage existing knowledge on server
- 21. Stack • CoffeeScript (hi haters!) • Express • Mustache & custom view engine • Custom asset pipeline
- 22. Boundaries • Apps only talk to REST API and Memcached • Layout is in a separate application • Shared common asset bundle
- 23. Design Goals • Simple controllers • Render from the server • Skip fancy performance optimizations • Make the API a bottleneck • Resilience when services fail
- 24. Simple Design module.exports = 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
- 26. Subscribe Page • Simple application • Partial implementation • Proved out the concept
- 28. Growing Pains • Max sockets • Breaking our infrastructure
- 30. New problems • User authentication • More service calls • Complicated routing • More traffic • Share look and feel
- 33. grout Switchboard for incoming requests to I-Tier applications • domain • locale • country • experiments
- 34. grout • groupon.com/deals/my-awesome-deal • itier-deal-page-vip.snc1/deals/my-awesome- deal • groupon.de/browse/berlin • itier-browse-page-vip.lup1/browse/berlin
- 35. grout • Experiments between different applications on the same URL • Testing between alternative implementations (including the legacy monoliths!)
- 38. gconfig • Configuration as a service • Some config can change on the fly • Config can be promoted from uat -> staging -> prod
- 40. Layout • Distribute layout as library • Use ESIs for top/bottom of page • Apps are called through a “chrome service” • Fetch templates from service
- 41. Layout Service • Independent rollouts • Changes can be shipped without re-deploying all apps • Easy to use in development
- 42. Layout Service • Uses semantic versioning • Roll forward with bug fixes • Stay locked on a specific version • Enable site-wide experiments
- 45. Rewrite All The Things!
- 46. Rewrite • Get the whole company to move at once • Supporting two platforms is hard • Transition from June 2013 to September 1, 2013
- 47. Rewrite • ~150 developers • Global effort • Feature freeze – A/B testing against mostly the same features
- 48. What Went Well
- 49. It worked!
- 53. What Didn't Go Well
- 54. Negatives of SOA • Increased testing burden • Tooling needs to catch up • Increased operational overhead
- 55. Culture Problems • Changed team workflow • Teams are silos • Code quality varies
- 56. Next Steps • Better resiliency to outages • Distributed tracing • International (launching now) • Open Source - Testium
- 57. tl;dr • Kill web monolith • Federated frontend • Service oriented architecture • grout • gconfig • Layout service