Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Scaling Gilt: from Monolithic Ruby Application to Distributed Scala Micro-Services Architecture

3.875 Aufrufe

Veröffentlicht am

Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/10fVilQ.

Yoni Goldberg describes some of the technological innovations that have helped Gilt to reach its current size, and highlight some of the core challenges that the company's engineering team continues to face. He also discusses what every tech team needs to consider and address before heading down the path of building a first-class micro-services architecture. Filmed at qconnewyork.com.

Since joining Gilt at 2010 as a platform engineer, Yoni Goldberg has been leading a variety of personalization efforts and other customer-facing initiatives--including the Gilt Insider loyalty program, the post-purchase experience, and SEO/optimization efforts. Prior to joining Gilt, Yoni worked at Google, where he wrote his master's thesis on Fusion Tables.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

Scaling Gilt: from Monolithic Ruby Application to Distributed Scala Micro-Services Architecture

  1. 1. SCALING GILT From Monolith Ruby App to Distributed Scala Micro·Services QCon · Brooklyn · 2014
  2. 2. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations/ scale-gilt InfoQ.com: News & Community Site • 750,000 unique visitors/month • Published in 4 languages (English, Chinese, Japanese and Brazilian Portuguese) • Post content from our QCon conferences • News 15-20 / week • Articles 3-4 / week • Presentations (videos) 12-15 / week • Interviews 2-3 / week • Books 1 / month
  3. 3. Presented at QCon New York www.qconnewyork.com Purpose of QCon - to empower software development by facilitating the spread of knowledge and innovation Strategy - practitioner-driven conference designed for YOU: influencers of change and innovation in your teams - speakers and topics driving the evolution and innovation - connecting and catalyzing the influencers and innovators Highlights - attended by more than 12,000 delegates since 2007 - held in 9 cities worldwide
  4. 4. - GiltDirect, Sale Personalization, Loyalty, SED, Post-purchase, Login/Registration - MIT eS BS/Meng I Google I IBM I IDF - Israel I Brooklyn I eoffee I JS/Node I Arduino I Running I Kite Surfing I Poker
  5. 5. The lessons and challenges that we had/have with micro·service architecture
  6. 6. WHAT IS GILT? Flash Sales Business Founded in 2007 Top 50 Internet-Retailer ~150 Engineers
  9. 9. THE EARLY DAYS 2007 - Ruby on Rails the hottest new thing The goal was to get to market fast
  10. 10. We were able to handle our traffic pretty well
  12. 12. TECHNOLOGY PAIN POINTS · 2009 Spike required to launch 1,000s of ruby processes Postgres was overloaded Routing traffic between ruby processes sucked INote to selfI hide from the ruby fans
  13. 13. DEY 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
  15. 15. THREE THINGS HAPPENED Started the transition to the JVM M(a/i)cro-Service Era Started Dedicated data stores
  16. 16. WHY JVM? Widely adopted Stable Better support for concurrency Better GC vs MRI
  17. 17. FIRST 10 SERVICES
  18. 18. We solved 90% of our arch scaling problem But not the Dev points
  19. 19. SOLVED PAIN POINTS Spike required to launch 1,000s of ruby processes Postgres was overloaded Routing traffic between ruby processes sucked
  20. 20. STILL OPEN PAIN POINTS New services became semi-monolithic 1000Models/Controllers, 200K LOC, 100s of jobs Lots of contributors + no ownership Difficult deployments with long integration cycles
  21. 21. WHY WE DOUBLED DOWN ON MICRO·SERVICES Empower teams and ownership Smaller scope Simpler and Easier deployments and rollbacks
  22. 22. As of last week we have around 400 services in Prod
  23. 23. We began the transition to Scala and Play LOSA • Lots Of Small (Web) Apps Same as micro-services but for web-apps
  24. 24. DEMO
  25. 25. why the increase?
  26. 26. APP BOOTSTRAP rake bootstrap:admin-web # Bootstrap a ad rake bootstrap:babylon-docs # Bootstrap rake bootstrap:client-server-core # Bootstrap rake bootstrap:jersey-java # Bootstrap rake bootstrap:jersey-scala # Bootstrap rake bootstrap:play # Bootstrap rake bootstrap:play-ui-build # Bootstrap rake bootstrap:sbt-library # Bootstrap rake bootstrap:schema # Bootstrap
  27. 27. HOW TO DEFINE A MICROSERVICE? Functionality scope Number of devs involved
  28. 28. NEW CHALLENGES Deployments and Testing (Functional/lntegration) Dev/lntegration Environments Who owns this service!? Monitoring
  29. 29. ON DEPLOYMENTS AND TESTING "Testing isHARD" - the dev that sits on your left
  30. 30. T HE C H A LLENG ES TH A T WE FACED: Hard to execute functional tests between services Frustrating to deploy semi-manually (Capistrano) Scary to deploy other teams services
  31. 31. SBT Motivation: Scala adaption Complex Scala syntax Cool features: ~test, shell, console Hard to debug
  32. 32. 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')
  33. 33. ION·CANNON + SBT Run tests on dedicated Env Supports Canary releases Easy rollbacks Integrated health checks
  34. 34. On Dev/lntegration Environments The hardware is not strong enough No one wants to compile 20 services Service Dependencies
  35. 35. EACH TEAM HAS A STAGING ENV SERVICE_PORTS=[ 4001, #listing-service 8235, #svc-user-set 9420, #svc-free-fall 7895, #svc-Loyalty 8155, #web-loyalty 9410, #web inventory status 7898, #admin-loyalty 7899, #notification 7102, #rouge 9530, #svc-component
  36. 36. 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)
  37. 37. Dependency Fun [Demo]
  38. 38. THE FUTURE GO Reactive
  39. 39. Docker An extension to Linux Containers (LXC) Decentralization SimpleConfigurations Much lighter than a VM Immutable Supports multiple platforms
  40. 40. ON OWNERSHIP "code stays much longer than people" - SB
  42. 42. CURRENT APPROACH Code Review!Code Review!Code Review! Team owns services, not individual developers Ownership transfer
  44. 44. WE TRANSITIONED TO MICRO· DBS Third of the services have their own MongoDB I Postgres I Voldemort
  45. 45. MANAGE MICRO·RELATIONAL DBS SCHEMA EVOLUTION MANAGER https://github.com/gilt/schema-evolution- manager
  46. 46. 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
  48. 48. THE TOOLS WE USE graphite / openTSDB
  49. 49. Cheat Sheet Your organization has > 30 developers Deployments and integrations are difficult [You need a team for that] You can abstractly separate features and parts of your site Special hardware or performance needs for some features
  50. 50. MAIN TAKEAWAYS Simplicity - Do you really need it? MicroServices promise works for most case As of 2014 - You will need to invest in Tools We feel that it was the right choice for us
  52. 52. QUESTION TIME We are hiring... @yoni_goldberg jgoldberg@gilt.com www.yonigoldberg.com
  53. 53. SCALA BREAK
  54. 54. Why switch to Scala from Java Object-Functional Programming Akka Immutability that leads to easier concurrency Great libraries: like Salat, Scalaz Less boilerplate code - e.g Case classes, App Scala's Collections
  55. 55. Traits Cake Pattern Console SBT (in scala, release process) Option
  56. 56. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations/scale-gilt