Gilt from monolith ruby app to microservice scala service architecture

668 views
602 views

Published on

The presentation that I gave at the 'NYC Tech Talks' meetup @ January 14, 2014

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
668
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
18
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Gilt from monolith ruby app to microservice scala service architecture

  1. 1. SCALING GILT From Monolith Ruby App to Distributed Scala Micro-Services #NYCTECHTALKS Yoni (Jonathan) Goldberg Lead Engineer - GILT Podium => http://bit.ly/podiumapp
  2. 2. ABOUT ME - Leading the Popeye Team - Sale Personalization, Loyalty, SEO Post-purchase, Login/Registration flows - MIT CS BS/Meng | Google | IBM | IDF - Brooklyn | Coffee | Arduino | Running | Kite Surfing | Online Collaboration | Poker Excited to be part of the NYC Tech community
  3. 3. THE LESSONS AND CHALLENGES THAT WE HAD/HAVE WITH MICRO-SERVICE ARCHITECTURE
  4. 4. WHAT IS GILT? Flash Sales Business Founded in 2007 Top 50 Internet-Retailer ~150 Engineers
  5. 5. ANOTHER WAY TO LOOK AT GILT Three day traffic pattern
  6. 6. THE CLASSIC STARTUP STORY
  7. 7. THE EARLY DAYS 2007 - Ruby on Rails the hottest new thing The goal was to get to market fast
  8. 8. WE WERE ABLE TO HANDLE OUR TRAFFIC PRETTY WELL
  9. 9. UNTIL LOUBOUTIN CAME TO GILT
  10. 10. TECHNOLOGY PAIN POINTS - 2009 Spike required to launch 1,000s of ruby processes Postgres was overloaded Routing traffic between ruby processes sucked |Note to self| - hide from the ruby fan boys
  11. 11. DEV PAIN POINTS 1000 Models/Controllers, 200K LOC, 100s of jobs Lots of contributors + no ownership Difficult deployments with long integration cycles Hard to identify root causes
  12. 12. WE NEEDED TO SOLVE THE PROBLEM FAST
  13. 13. THREE THINGS HAPPENED Started the transition to the JVM M(a/i)cro-Service Era Started Dedicated data stores
  14. 14. WHY JVM? Widely adopted Stable Better support for concurrency Better GC vs MRI
  15. 15. FIRST 10 SERVICES
  16. 16. We solved 90% of our arch scaling problem But not the Dev points
  17. 17. PAIN POINTS Spike required to launch 1,000s of ruby processes Postgres was overloaded Routing traffic between ruby processes sucked New services became semi-monolithic 1000 Models/Controllers, 200K LOC, 100s of jobs Lots of contributors + no ownership Difficult deployments with long integration cycles
  18. 18. WHY WE DOUBLED DOWN ON MICRO-SERVICES Empower teams and ownership Smaller scope Simpler and Easier deployments and rollbacks
  19. 19. MICRO SERVICE ARCHITECTURE STARTED TO GET TRACTION
  20. 20. AS OF LAST WEEK WE HAVE MORE THAN 450 SERVICES
  21. 21. APP BOOTSTRAP rk bosrpamnwb ae otta:di-e #Bosrpaamnwbsrie otta di-e evc rk bosrpbblndc ae otta:ayo-os #Bosrpabblndc srie otta ayo-os evc rk bosrpcin-evrcr #Bosrpacin-evrcr sr ae otta:letsre-oe otta letsre-oe ev rk bosrpjre-aa ae otta:esyjv #Bosrpajre-aasrie otta esyjv evc rk bosrpjre-cl ae otta:esysaa #Bosrpajre-cl srie otta esysaa evc rk bosrppa ae otta:ly #Bosrpapa srie otta ly evc rk bosrppa-ibid ae otta:lyu-ul #Bosrpapa-ibidsrie otta lyu-ul evc rk bosrpstlbay ae otta:b-irr #Bosrpastlbaysrie otta b-irr evc rk bosrpshm ae otta:cea #Bosrpashm srie otta cea evc
  22. 22. WE BEGAN THE TRANSITION TO SCALA AND PLAY LOSA - Lots Of Small Apps Same motivation and benefits of Micro-Service Architecture
  23. 23. NEW CHALLENGES Dev/Integration Environments Who owns this service!? Monitoring Deployments and Testing (Functional/Integration)
  24. 24. ON DEV/INTEGRATION ENVIRONMENTS The hardware is not strong enough No one wants to compile 20 services
  25. 25. EACH TEAM HAS A STAGING ENV SRIEPRS[ EVC_OT= 40,#itn-evc 01 lsigsrie 83,#v-srst 25 scue-e 92,#v-refl 40 scfe-al 79,#v-oat 85 scLyly 85,#e-oat 15 wblyly 91,#e ivnoysau 40 wb netr tts 79,#di-oat 88 amnlyly 79,#oiiain 89 ntfcto 70,#og 12 rue 93,#v-opnn 50 sccmoet 60,#v-atitsbi 82 scwils-umt 46,#v-cinsl 06 scato-ae .. .. PR_OWR_RSSRIEPRSmp{|ot OTFRADAG=EVC_OT.a pr| [-' "{ot:oahs:{ot" 'L, #pr}lclot#pr}] } ee([wsh- - - -} PR_OWR_RS G_OT.l xc*%{s a C N n, OTFRADAG, WHS]f
  26. 26. STAGING DIFFICULTIES: Hard to keep all the services up to date Maxed our staging env capacities Requires to have internet connection for some of the services (e.g LOSA-apps)
  27. 27. The Future
  28. 28. DOCKER An extension to Linux Containers (LXC) Decentralization Simple Configurations Much lighter than a VM Immutable Supports services and platforms
  29. 29. ON OWNERSHIP "code stays much longer than people" - SB
  30. 30. CODE OWNERSHIP
  31. 31. CURRENT APPROACH Code Review!Code Review!Code Review! Team owns services, not individual developers Ownership transfer
  32. 32. DATA OWNERSHIP
  33. 33. WE TRANSITIONED TO MICRO-DBS Third of the services have their own MongoDB Postgres Voldemort
  34. 34. MANAGE MICRO-RELATIONAL DBS SCHEMA EVOLUTION MANAGER https://github.com/gilt/schema-evolution-manager
  35. 35. PRINCIPLES OF SCHEMA EVOLUTION MANAGER Can manage the schema evolutions in a Git repo Schema changes are deployed as tar flies No rollbacks Schema changes are required to be incremental
  36. 36. eh "raetberlae (ditgr">nwsl co cet al eess i nee) e.q smad.nwsl#rae agtcmi e-d /e.q Cetd i omt smds #gnrtstetregshm-o-ann...a. e-it eeae h a . ceaincno002tr #Spadutro yu sre c n na n or evr c shm-o-ann002 d ceaincno-.. smapyhs -lclot-nm incno -ue incn e-pl ot -oahs -ae o-ann -sr o-an
  37. 37. ON MONITORING
  38. 38. THE TOOLS WE USE graphite / openTSDB
  39. 39. ON DEPLOYMENTS AND TESTING (FUNCTIONAL/INTEGRATION) "Testing is HARD" - the dev that sits on your left
  40. 40. THE CHALLENGES THAT WE FACED: Hard to execute functional tests between services Frustrating to deploy semi-manually (Capistrano) Scary to deploy other teams services
  41. 41. SBT Motivation: Scala adaption Complex Scala syntax Cool features: ~test, shell, console Hard to debug
  42. 42. GILT-SBT-BUILD Simple config for all the services Pulls many plugins: [nexus, testing, RPMs, run scripts, Monitoring, SemVer, ...] Custom commands (e.g 'sbt release')
  43. 43. ojc BidetnsCinSreCrPoetwt Dpnece { bet ul xed letevroerjc ih eednis vlnm ='v-aeatvto' a ae scsl-ciain vlcrDp =.. a oees .. vlsreDp =.. a evres . vlcinDp =.. a letes . oerd vlinannrc =InannFsTak vrie a ocnoTak oCno.atrc }
  44. 44. ION-CANNON + SBT Run functional/Selenium tests on dedicated Env Supports Canary releases Easy rollbacks Integrated health checks
  45. 45. MAIN TAKEAWAYS Simplicity - Do you really need it? We feel that it was the right choice for us MicroServices promise works for most cases As of 2014 - You will need to invest in Tools!
  46. 46. PODIUM TIME We are hiring... Keep in touch: jgoldberg@gilt.com www.yonigoldberg.com

×